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A.       OBJECTIVE,  AUDIENCE,  AND  NEED 

o        Data  Administmtion  (DA)  is  becoming  more  sophist icatedj^^iiTTgublicity^nd 
claims  atjuul  tfare  growing.  So-is--eonfusioBi^he  objective  of  this  report  is 


to: 

Clarify  what  DA  is  and  is  not. 

% 

Delineate  the  pressures  affecting JA. 

Define  related  concepts,  such  as  data  and  information. 

Provide  clear  guidelines  for: 

Deciding  what  specific  enterprises  would  benefit  from  DA. 

Technically  establishing  or  strengthening  DA. 

Coping  with  the  human  aspects  of  DA. 
o    ^   Primary  audience  is  infprnatijPp  systems  (IS)  managers  who  need  a  better 


understanding  of  DA  an^«  guidebook  to  management. 


A 


econdary  audience  is  data  administrators  and  data  base  administrators 
who  need  to  mesh  their  operations  with  broader  organizational  goals. 
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ySL  Jerj\aTy  audience  is^endors  of  DA  tools  and  consulthg  who  need  a 
'     broader  understanding  of  their  markets. 


B.       SCOPE  AND  METHODOLOGY 

o        This  report  is  part  of  the  Infornnation  Systems  Program  (ISP)  Corporate 
Systems  Planning  Program.  It  addresses  the  following  issues: 

Current  trends  and  pressures  affecting  j^ata  i^dministration  (DA)  ^ 
(Chapter  III). 

Versus  v  *y  / 

The  theoretical  promise^  of  DA  a«dj«fl^act ua I ,-etjrrewr  experience  ^ 

with  it  (Chapter  IV). 


Guidelines  for  determining  what  kind  of  organization  would  benefit 
from  DA  (Chapter  V). 

Functions  to  be  performed  in  establishing  a  technically  sound  DA 
operation  (Chapter  VI). 

Human  aspects  of  DA  (Chapter  VII). 


J 


Recommended  strategies  for  using  DA  (Chapter  VIII). 
o        Information  from  this  report  was  gathered  from  the  following  sources: 

Y 

Interviews  with  four  aeadomic  and  regcarch-^specialists  in  DA. 
Interviews  with  six  vendors  of  DA  tools  and  consulting  services. 


Structured  interviews  with  18  managers  in  organizations  with  data  base 
management  systems  or  DA  operations. 
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o        Types  of  organizations  included  are: 

Banking,  finance,  and  insurance  companies. 

Commercial  manufacturers. 

Aerospace  manufacturers. 

Large  public  utility  companies. 

A  large  state  university  system. 

o        The  conclusions  and  recommendations  in  this  report  are  a  synthesis  of  INPUT'S 
experiences  plus: 

The  procedures  and  results  reported  by  the  organizations. 

The  most  sensible  proposals  from  the  vendors. 

The  most  impressive  ideas  from  the  researchers. 

C.       RELATED  INPUT  REPORTS 


o        Background  and  amplification  of  some  of  the  concepts  in  this  report  may  be 
found  in  five  other  INPUT  reports: 

Micro-to-Mainframe  Systems  Experiences,  May  1 984. 

Will  concentrate  on  the  experiences  of  organizations  that  use 
personal-computer-to-mainframe  systems.  It  will  also  identify 
systems  requirements  and  project  future  effects. 
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Integrating  Systems  and  Corporate  Planning,  March  1 984. 


Describes  approaches  to  achieving  an  integrated  infornnation 
system  opd  corporate  business  planning  process  that  also 
achieve^  full  benefits  from  information  technology. 

The  Opportunities  of  Fourth-Generation  Languages,  September  1 983. 

Analyzes  the  extent  to  which  fourth-generation  languages  are 
used  and  how  they  fit  into  the  information  systems  strategy. 

Organizing  the  Information  Center,  August  1 983.  ^ 

Discusses  how  to  organize  an  information  center,  including 
chargeback  methods. 

Personal  Computers  oinJ-the  IS  Strategy,  December  1 982. 

This  report  recommends  the  most  effective  ways  for  IS  to 
become  involved  with  personal  computers  (PCs). 
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EXECUTIVE  SUMMARY 


Note:  this  executive  summary  is  designed  in  a  presentation  format  in  order 
to: 

Help  the  busy  reader  quickly  review  key  research  findings. 

Provide  a  ready-to-go  executive  presentation,  complete  with  a  script, 
to  facilitate  group  communication. 

The  key  points  of  the  entire  report  are  summarized  in  Exhibits  II- 1  through  II- 
io  |.  On  the  left-hand  page  facing  each  exhibit  is  a  script  explaining  its 
contents. 
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A. 


DATA  ADMINISTRATION  EXPERIENCE  AND  OUTLOOK 


o        This  report  was  produced  as  part  of  INPUT'S  Information  Systems  Program 
(ISP). 

o        Data  Administration  (DA)  is  receiving  increasing  publicity,  and  for  good/^ 
reasons: 

By  improving  the  accessibility  and  quality  of  the  data,  1^  can  improve 
computing  on  personal  computers,  etc. 

The  same  factors  can  raise  the  speed  and  quality  of  professional 
programmers'  work. 

Better  understanding  of  data  can  also  make  Management  Information 
System^eports  more  iro\^ informative.  Executive  perspectives  can  be 
better  represented. 

o        The  new  report: 

Distinguishes  between  DA  and  related  functions  such  as  data  base 


administration. 


Explains  the  theoretical  promises  of  DA  and  cites  relevant  aetuat-  ^ 
experiences. 

Contains  guidelines  for  estimating  an  enterprise's  need  for  DA. 
Contains  clear  "how  to  do-rtiJ' sections  on  DA. 


Explains  the  technical  goals  that  must  be  met. 
^  ^dvise»  on  the  human  aspects  of  DA. 
Offers  a  strategic  guide  to  the  use  of  ihe  iilf^rrrluHon  in  Hie  report. 
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B.       FOCUS  ON  DATA  FACILITATES  PROGRAMMING 


o        Conceptually,  DA  takes  a  new  view  of  data. 

o        Traditionally,  orientation  has  been  toward  computers  and  programs. 

A  program  was  written/ and  often  a  data  base  was  generated  just  for 

•\.  ^  ^ 

that  program. 

For  economy's  sake,  closely  related  programs  tapped  an  identical  data 
bas^^BS'TttPstratod  in  Exhibit  il-2; — ^ 

A  program  can  feed  information  to  a  different  data  base  under  certain 
conditions,  but  normal ly^^g^^^'^fi^iyi^'^lTcfp  this  process. 

o        The  orientation  of  DA  is  primarily  toward  the  data  rather  than  toward  the 
programs  and  computers. 

o        DA  seeks  to  integrate  the  data  bases  within  an  enterprise. 

Thew^ograms  can  be  more  readily  built  on  these  data. 

Query  languages  and  fourth-generation  languages  can  more  readily  be 
used  to  "massage"  the  data. 

Higher  interpretations  of  the  data  will  offer  more  meaningful 
information. 

o        The  trick  to  all  of  this  is  to  control  the  data:  to  standardize  th^i^ 
configuration,  map  access  routes  to  thorn|[  and  control  changes 
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c. 


INFORMATION  DEPENDS  ON  ITS  ENVIRONMENT 


o        "Uncertainty"  can  be  defined  mathematically.  Information  is  that  which 
reduces  uncertainty. 

One  bit  of  information  reduces  uncertainty  by  one-half. 

If  you  are  told  which  half  of  a  football  field  the  ball  is  on,  your 
uncertainty  is  reduced  by  one-half. 

If  a  computer  printout  tells  which  of  two  machines  is  causing 
more  defects,  your  uncertainty  is  reduced  by  one-half.  Ttre-^ 
l^rifftetrt-ghms'yaTronBijit  of  infonriation:  ^ 


The  key  to  information  is  the  matrix  in  which  it  fits. 


Without  the  concept  of  the  football  field,  the  location  of  the 
ball  would  carry  no  information. 

Without  the  matrix  of  comparison  of  the  two  machines,  the  data 
on  the  computer  printout  would  convey  no  information. 


A  major  challenge  to  DA  is^to  see  tha^^ta  lose^o  information  as  they  are 
transferred  from  one  matrix  to  another  ^  to  restructure  the  data  to  provide 
information  to  the  new  matrix. 
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D.       DATA  ADMINISTRATION  BUILDS  AN  INFRASTRUCTURE 


o        A  serious  practical  problem  in  justifying  DA  is  that  its  existence  really 
demands  an  infrastructure. 

An  integrated  data  base^j4ke-ll lu I  illusliuled  ul  Ihe  bottom  of  E^chffarf 

an  infrastructure.  It  is  analogous  to  automated  telephone 
switching  equipment  or  to  a  network  of  power  lines. 

Any  infrastructure  requires  a  capital  investment. 


This  investment  can  rarely  be  justified  by  any  single  application. 

An  automated  switching  system  for  any  single  residential 
telephone  customer  would  not  make  economic  sense. 

A  large  integrated  data  base  for  any  single  application  program 
would  not  make  economic  sense. 

However,  many  applications  are  predicted  -  some  logically  and  some  on 
faith. 

Current  experience  indicates: 

.         The  predictions  of  faster  application  programming  and  more 
satisfied  end  users  are  valid. 

Some  improvement  in  management  information  ere  reported; 
e.g.,    manufacturing  company  defined  a  profitable  market. 

Major  manufacturing  firms  have  high  ambitions;  they  want  to 
integrate  information  to  improve  the  "organicity"  of  their 
manufacturing. 
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E.      eOM  IS  THE  TECHNOLOGICAL  KEY  TO  BA 


o        The  technical  germ  of  ©A  is  the  "three-scheme  architecture." 

o        Data  needed  by  the  enterprise  can  be  organized  into  a  conceptual  map  called 
the  Conceptual  Data  Model  (CDM). 

The  CDM  is  described  independently  of  any  device  that  will  hold  the 
actual  data. 

The  CDM  is  also  described  independently  of  any  particular  user's  view 
of  the  data. 

The  CDM  is  exposed  to  a  vital  technical  process  called  "normalization." 

Normalization  is  to  the  CDM  what  the  alphabet  is  to  a 
dictionary. 

Without  normalization,  a  CDM  would  lack  a  logical  access  path. 

Without  normalization,^  would  lack  a  framework  unaer  which 
new  entries  could  be  classified. 

A  business  model  is  developed  to  make  sure  the  CDM  does  contain  a 
framework -+1^ which  to-represem  all  of  the  information  needed  by  the 
enterprisCpgiM  tCM\  l^t  >\jejU£4jfi'l'»Xi^  , 


-  6  -  (U-CDA-II)  ML  5/7/84 


BARRIERS  EXIST.  BUT      IS  RECOMMENDED 


DA  is  recommended  for  any  organization  in  which  data  control  is  a  problem 
and  in  which  data  exploitation  is  an  opportunity. 

Lack  of  DA  causes  problems  with  data  that  are  redundant,  inaccurate, 
unavailable. 


Evidence  indicates  that  DA  produces  more  effective  programming  and 
contributes  to  more  informative  management  information  systems 
(MIS). 


Technical  and  human  barriers  stand  in  the  way  of  DA. 

-ru  *    u  •    1  u     •  u    OVtrCirwU  ^  a 

I  he  technical  barriers  can  be  sjur$not»nteer  d  u     i  U 

.y'"^  Th^  tf-JPUT  rsport  doocrjboo  and  summarizes  the  neces&ary 
teel=»mquesr 


Sources  -  consultants  and  software  tools  -  are"" 
i^^  the  report. 


Human  barriers  can  be  minimized. 


Rational,  understandable  explanations  can  be  given  to  top 
management  whose  support  is  essential  to  DA's  success. 

Any  new  technology  changes  the  roles  people  play  in  on 
organization,  and  the  integrated  data  base  technology  behind  DA 
is  no  exception.  By  understanding  the  pressures  on  them,  most 
people  can  adapt  to  these  changes. 
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TRENDS  AND  PRESSURES  IN  DATA  ADMINISTRATION 


A.  WHAT  IS  GOOD  DAT 


I.       HISTORY  AND  DEFINITIONS 

o        Data  Administration  (DA)  is  a  relatively  new  and  inconsistently  defined 
concept. 


Datc^ase  Management  Systems  (DBMSs)  appeared  in  the  late  1960s. 

Data  Dictionaries  (DDs)  emerged  in  the  1970s. 

The  term  DA  was  not  generally  used  until  the  1980s. 

.         Now  there  is  a  population  explosion  of  new-born  articles  about 
DA  and  related  concepts. 

A  new  journal,  Database,  concentrates  exclusively  on  datiase- 
related  reports.  Widely  circulated  magazines  sucn  as 
Datamation  and  lnf(^ystems  are  trying  to  pVdefine  DA/and.(2f 
tell  their  readers  where  DA  should  be  located  in  their 
organizations. 

The  magazine  writers  DA  very  positively.  They  cite  its 
value  in  "taming  .  .  .  uncontrolled  dat^xises"  and  thereby 
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ig y\)  the  danger 


This  definitionlis  really 


IN 


reducing  jfi)  the  danger  of  lost  and  inaccurate  data/and ji^  the 
cost  of  redundant  storage. 

/hree  different  scopes  of  rooponsibility  qre  carved  oul  JifreiLi-vj  definitions 
of  DA.  , 

In  the  weakest  and  narrowest  defioiiioo,  DA  is  merely  the  "care  and 
feeding"  of  a  DBMS:y^ maintaining  its  software,  supporting  applications 
programmers  who  use  the  DBMS,  protecting  datdbase  integrity  and 
standards,  etc.  "^A 

This  definition  is  wrong,  according  to  most  writers  and  almost 
all  the  people  surveyed  by  INPUT. 

\  ^ 

iox  Datcfoase  Administration  (DBA). 

•  V 

In  the  most  frequent  definition,  DA  is  DBA  plus  broader  business 
functions:  \> 

.  ^    Keeping,  higher  executives  informed  of  the  challenges  and 
opportunities  in  data  management. 

^  I4eepti°ig  informed  of  tW  corporate  goals,  and  reflecting  ^^^in 
the  data  structures. 

DA  also  has  different  tools  and  powers  than.  DBA. 

The  DA  function  would  be  impotent  without  a  DD.  The  DD 

contains  metadata  (i.e.,  data  about  data).     The  metadata 

describe  the  company's  basic  data,  the  users,  and  the  data 
processes  and  processors. 
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.         DA  holds  "the  keys  to  the  kingdom"  in  its  control  over  the  DD: 
'  DA'^ability  to  enter  the  DD,  report  its  contents,  and 

modify  them. 

The  term  Information  Resource  Management  (IRM)i«' frequently  used 
to  nFwan  the  Aciiiie  Hung  as  the  above  definition  of  DA.-^So  i'>  DulO 
■Munuyeiiieiil. — 


The  strongest  definition  includes  the  above  plus  a  proactive 
responsibility:     to  derive  information  that  will  influence  corporate 

—  y 

goals,  and  even  help  create  new  ones.  INPUT  believes  this  is  the 
proper  definition  for  DA. 


This  type  of  DA  needs  a  business  model  (described  in  Chapter  VI)  to  add 

^  its  functions. 
-V- 

A  business  model  derives  from  what  c^^business  does  and  not 
from  what  happens  to  be  in4^£resgQl-^iatabases. 

l+-cu4s  in  the  anticipation  of  corporate  needs  for  information. 


Exhibit  III- 1  illustrates  these  definitions. 

Few  organizations  have  a  DA  function  that  meets  the  strongest  definition. 

Only  about  a  quarter  of  the  mainframes  now  in  use  support  DBMSs.  (A 
higher  percentage  do  have  some  kind  of  datcobase  technology.) 

\ 

In  that  quarter,  most  have  a  rather  narrowly  defined  DA  function. 

Most  DBMSs  are  not  used  optimally.  This  opinion  is  widely  held  by  the 
INPUT  respondents,  and  especially  by  the  academic  researchers  and 
commercial  consultants. 
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Representative  comments  include:  ".  .  .  only  a  few  (firms)  have 
truly  implementedJ^DA?*' 

"Advertisements  constantly  appear  for  programmers  with 
experience  in  particular  datc^ase  products.  (But)  jft  is  rare  to 
find  a  succinct  description  of  a  datc^ase  job  dealing  primarily 
with  the  company's  information  requirements." 

"Most  DpMS  users  continue  to  use  the  same  analysis  and  design 


methods  as  they  used  without  DBMS  and  thu^ave  produced  one 
dat^ase  per  application  instead  of  multipurpose,  shared 
datcbases." 

How  many  DA  functions  are  operating  now?  The  answer  depends  on 
one's  definition  of  DA.  Exhibit  III-2  shows  (I)  the  estimated  number  of 
IS  organizations  with  hardware  that  could  support  DA,  but  which  have 
essentially  no  DA  function;  and  (2)  estimated  numbers  as  a  function  of 
how  weakly  or  strongly  DA  is  defined. 

All  consultants  contacted  by  INPUT  agreed  that  the  DA  concept  is 
spreading.  As  Exhibit  1 1 1-2  shows,  there  is  much  room  for  growth. 

Bef^reJ^^di^ng  most  of  the  candidate  sites,  commonly/def ined  DA 
could  grow  by  a  factor  of  ten. 

Strong  I  y^ef  ined  DA  could  grow  by  a  factor  of  50  before  reaching  most 
present  candidates. 

As  the  population  of  computers  grows,  so  will  the  number  of  locations 
needing  DA. 
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2. 


There  are  agreements,  in  principal,  of  what  constitutes  "good"  DA.  In 
genera  I  i+t«fi^good"  DA  can  be  defined  economically. 

A  company's  data  represent  an  investment.  It  is  as  real  as  the 
company's  investments  in  equipment^r  i^raining^,^oi*«peop4«r— ^ 

DA  is^a^ational  attempt  to  maximize  the  return  on  the  investment  in 


data!^^ 


-DA  is  good  foTHe  extervrifial  it  sucfcfeeds-in-tbig  attempt-.'^ 


o        "Good"  DA  can  also  be  defined  pragmatically. 

J^'is  good  to  the  extent  that  it  delivers  what  its  Infarmntinn  Syitrmr?' 
(B)-eommunityt;&ser?^  expect^>4elp  in  making  them  more  productive. 

DA  is  even  better  if  it  also  serves  as  the  basis  for  realistic,  top-level 
overview  reports  to  executives. 


B.       CURRENT  TRENDS  AND  PROBLEMS 


TECHNICAL  TRENDS 

Users  of  DA  andjj^s) services  are  changing.  In  the  past,  IS  had  clear lyVdefined 
users.  Therefore  it  seemed  to  have  clearly-tdefined  data.  Mnw  ■  .  .  Q 

V 
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^*^eTs  are  more  transient.  More  "amateurs^re  in  the  because^ 

They  want  to  use  their  persona!  computers  as^  personal 
information  delivery,  ongjnoo;  ^-^ 

rs 

Decision  support  systerr^  are  proliferating,  and  users  want  data 
for  them.  ^ 

Therefore  data  extraction  is  becoming  more  demand-fdriven.*^  less 
planned.  V 


The  physical  environment  of  DA  is  changing. 

Telecommuncations  are  becoming  much  nrioro  available. 


.         Local   area   networks  (LANs)  increase  the  volume  of  data 
communications. 

But  LANs  do  nothing  to  improve  the  quality  of  the  data. 
There  is  a  strong  trend  toward  distributed  processing. 
These  physical  trends  create  pressures  to  serve  more  remote  users. 


The^  companies'  mainframe  computers  have  lost  their  monopoly  on  large 
datc/)ases.  External  data  are  increasingly  available  through  commercial,  on- 
line'^ database  services.  With  the  proper  micro  or  terminal^.—^' 

i 

The  company  marketing  department  can  call  up  external  databases  to 
review  "Sources^ought"  in  the  "Commerce  Business  Daily.'**'^ 

The  company  physician  can  ask  for  references  to  current  medical 
information  from  a  service  sanctioned  by  the  Amercian  Medical 
Association. 
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NonV^ecialists  can  interrogate  encyclopedic  datd|3ases  such  as 
DIALOG,  BRS,  and  ORBIT.  ^ 

A  bank  in  Massachusetts  can  now  legally  exchange  masses  of  data  with 
affiliated  banks  in  Rhode  Island,  Maine,  and  Connecticut.   There  is  a  i^lp^^/ 
legal  as  well  as  a  technical  trend  toward  regional  bankina.  i>4'*''* 

PUBLICITY  AND  PROBLEMS  V 

The  above  trends  generate  publicity»-not  ■  onl/  about  the  causes\(e.g.,  the-  Jtlftfrt 
personal  computers  and  decision  support  systems),  Uuh-ubuul  their  ef f ect^^jS^  \^ 

The  concept  of  DA  (or  IRM)  is  being  diffused  Into  the  IS  culture. 

Underlying)^theoretical  data  structures  are  seen  as  stable,  whereas 
applications  and  technology  are  constantly  changing.  So,  in  a  search 
for  stability,  some  people  cling  to  data  rather  than  -f^echnology. 


Some  people  see  the  traditional  IS  departments.obsolete.  TTjsfp  viev^ 
affected  by  publicity  about  the  power  ^f,'^'^ 

Decision  support  systems  (DSSs) 

f 


Fourth.generation  languages 


Personal  Computers  (PCs) 

These  trends  cause  problems. 

True  believers  in  program  documentation  are  appalled:  "For  thirty 
years  we've  failed  to  get  proper  documentation  out  of  professional 
programmers.  Now  what  can  we  expect  out  of  a  bunch  of  amateurs 
with  PCs?" 
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INPUT  heard  a  repeated  complaint:  "PCs  are  duplicating  datc|)ases  all 
over  the  connpany!"  Consultant  Dan  Appleton  warns  of  "information 
pollution."  If  only  because  of  PCs,  DA  has  a  harder  job:  It  is^more 
difficult  to:  ^ 


.         Avoid  redundancy  of  data, 
jnsure  security  of  data. 

Maintain  the  currency  of  data  (i.e.,  make  sure  no  one  is  using 
obsolete  data.) 

DA  can  help  solve  these  problems.  (Details  are  in  Chapter  IV.) 

Good  data  structures  facilitate  the  documentation  of  application 
programs. 

Strong  DA  can  control  data  pollution. 

Another  problem  arises:  Some  IS  people  don't  like  DA.  They  perceive  DA  as 
steoKftg  tneir  turf.  (See  Chapter  VII.) 

In  summary,  current  technical  trends  and  publicity: 

May  threaten  the  traditional  IS  department. 

May  make  IS  feel  hostile  to  DA. 
-        (Create  a  greater  recri^eed  for  DA  services. 
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C.      THE  NEW  PRESSURE;  WORK  IN.  FUN  OUT 


o        A  psychological  fact  will  become  increasingly  obvious. 

The  fun  in  using  a  PC  or  DSS  connes  mostly  from  getting  -w^ fhe 
resu  It^ 

-  .         PC  and  DSS  advertisements  focus  primarily  on 

When  *rtr+s  displayiog  interesting  results,-l+Te-f*C  is  a  nice  beast 
that-t^ntertainiog^^euJi/  ^ 

The  work  is  all  on  the  input  side. 

Data  entry  is  just  clerical  work. 

It's  frustrating  to  fuss  around  manually  finding^^ generatincLor 
reformatting  the  data.  )  I 

o        This  fact  (work  in,  fun  out)  carries  an  important  corollary:    Data  will  be 
shared.  ^ 

At  the  individual  level,  people  will  swap  data. 

At  this  level,  "good"  data  are  likely  to  be  defined  more  by 
shareability-^b^^^having  a  common  format— than  by  accuracy. 

.  This  unofficial  data^wapping  is  already  starting  to  happen.  One 
consultant  says:  "Because  the  necessary  databases  aren't 
created,  and  official  numbers  aren't  established,  a  l^lack  market 
of  data  Is  generated  by  users.  People  with  their  little  floppies 
are  now  running  down  the  halls  saying  to  each  othe^  'Here,  I've 
got  the  good  data.'" 
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Of  the  exchanged  data,  he  adds,  "^me  usually  are  inaccurate, 
some  of  them  are  outdated,  and  a 'lot  of  them  are  misleading^' 
because  of  lack  of  datOHiaming  standards." 

The  long  history  beht«d  data-/sweppi«g  is  summarized  in  Exhibit  III-3. 

Of  course  the  company  will  still  offer  data  to  users.  The  palatability 
of  this  offering  will  influence  the  extent  of  the  tendency  toward  data- 
swapping  by  individuals.  But  the  tendency  will  still  exist. 

DA  can  respond  in  either  of  two  ways  to  the  grassroots  trend  toward  dat<3^ 
sharing. 

It  can  fight  the  trend, 
it  can  facilitate  it. 


o        Good  DA  will  recognize  the  trend  and  facilitate  it. 


D.       LONGER-TERM  TRENDS 


I .       TOWARD  FOCUS  ON  DATA 

o  Harvard  Business  School's  Richard  Nolan  helped  define  the  DA  concept 
through  articles  in  the  Harvard  Business  Review.  In  1979  he  traced  a  typical 
big  business^^i^relationship  with  a  computer  through  six  stages.  (Comments 
about  the  stages  are  INPUT'S  as  well  as  Nolan's.) 

Initiation;  The  business  gets  its  first  computer. 
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Top  management  pays  attention  to  it. 

Single-file  applications  are  implemented  successfully. 
Contagion;  Applications  multiply. 

Top  management  relegates  responsibility  to  the  IS  professionals. 

IS  overcommits  itself,  and  its  budget  booms. 
Control;  Focus  is  first  on  the  budget,  then  on  the  technology. 


.         Top  management  fusses  tj^^  the  budget. 
.         IS  seeks  user  accountability  for  expenses. 

IS  considers  or  acquires  a  DBMS. 
Integration^'iyghvin^buty  tools  and  proceduresv^uU  * 


DBMSj  tend^to  be  used  first  as  irf^ubstitutej  for  file  access 
methods  (e.g.,  ISAM  and  VSAM). 


.         Newer  requests  are  grouped  into  functional  areas  (e.g.,  finance, 
manufacturing). 

A  need  becomes  clearer:  Vhe  identification  of  common  data  for 
these  areas. 

Pata  Administrntl(^|^is  Identified  by  the  strongest  def initioi^. 
The  DA  function  is  formally  established. 
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.         A  DD  is  acquired. 

Maturityi^jMrwb^  (not  quoting  Nolan^he  company  consciously  tries  to 


A  new  versTtJn  of  1+i«r  Nolan5stages  is  shown  in  Exhibit  111-4.  It  emphasizes  the 
common  and  moat  baai^  trenc^ 

Away  from  focusing  attention  on  hardware  and  computer  resources. 

Toward  focusing  attention  on  information  and  data  resources. 

This  version  uses  the  stages  as  a  scale  measure  the  IS  maturity  of 
individual  companies. 

V 

/Ti  \  \\\\  iiiilii.LiyV'the  maturity  of  IS  has  presented  ever-changing  questions  to 
executives.  These  are  outlined  in  Exhibit  III-5. 

On  any  scale,  the  bulk  of  industry  has  yet  to  reach  the  "mature"  stage. 

A 

As  technology  changes,  the  definition  of  "mature"  will  change. 
TOWARD  A  DATA  UTILITY 

J-  ^ 

M^ddkmanagers  have  an  in^easing  need  for  information.  (Aa'Section  III.F 
wrf+J^^pUiOyJ' information"  jnf  that  which  reduces  one's  uncertainty  about  a 
question;  ond^ata  produce  information  only  when  they  fit  it^some  kind  of 
"matrix"  or  frame  of  reference.) 

T^:>«^f  need  for  information  causes  meRogers  to  want  to  "message"  data.*  to 
"exercise"  different  models  quickly.  p 
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American  manufacturing  is  moving  toward  radically  shortened 
production  runs  and  an  Increasing  variety  of  products.  This  trend 
increases  the  need  for  DSSs  to  answer  "What  if"  questions  about  new 
factory  configurations  and  equipment. 

Financial  managers  need  support  in  dealing  with  increased  economic 
volatility. 


"What  if"  simulations  do  not  directly  concern  DA.  But  the  data  needed  for 
these  simulations  are" a  major  DA  issue. 


INPUT  respondents  agreed  that  "There's  a  lot  of  stored  data  out  there"  in  both 
corporation  and  application  databases.  There  was  also  agreement  on  the  basic 
challenge:  Ti 

To  control  the  data  (wth  beth  DDs  and  policies)  j  .  .  -O, 


so  anyone  can  use  th€ 


\%^^^  

A  trend  Qs_seei^ toward  the  Information  Center  concep^||o^^l5w«H^a  Data 
Utility^End  u^rs  would  "pfug  -WM^he  Data  Utility  ondTcreate  their  own 
reports.  juli^ 

A  consultant  oeheeti  a  dissenting  opinion:   The  concept  Is  good,  but  it 

/'doesn't  work'Nnow.  Rtjusuii;  Tl'ie  dulu  qre  poort  They  urn.':  * 
J-  'T^^oAo.  i$  -tea : 

.  Redundant. 
Hidden 


Out  of  date  inaccurate. 


♦\  Arra  the  data  access  mechanisms  are  not  user  friendly. 
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How  does  one  improve  the  data?  By  strengthening  the  DA  function  as 
indicated  in  Chapter  VI. 


o  The  popularity  of  the  information  Center  concept  is  a  symptom  of  the  outlook 
for  more  and  more  "consumer  computing."  This  outlook  creates  a  dilemma  for 
DA. 

The  pressures  for  consumer  computing  cannot  be  avoided. 

At  present  there  are  grave  danger^  Consumers  cannot  generally  be 
pciatce^ed  from  abusing  or  misusing  data. 

o  What  will  really  happen?  Some  INPUT  respondents  see  a  trend^over  the  next 
three  years^toward^omething  like  IMS  or  multiple  formats,  which  feed  a 
repository  of  DDSs,  which  produce  ^-..^omething  of  the  character  of  Lotus 
spread  sheets. 

o        The  industry  has  little  experience  with  $«dn  information  delivery  systems. 
Technically,  such  systems  could  be  built.    Tt>  LiuiiO,  ui  Ii6t  16  bulld?— ^Pj=t€>t-, 
s  basically  an  executive  decision. 


E.      THE  EXECUTIVE  VIEW 


I .       COMPETITIVE  FORCES 

o  IS  departments  ++ve-in  businesses  that  in  turn  live  in  a  world  that  is  becoming 
"smaller"  and  more  competitive.  Top  executives  respond  to  competitive 
forces  in  ways  that  affect  the  entire  IS  department. 
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"Pervasiveness  of  infornnation  gathering  .  .  .  -(end)- search  for  focused 
infornnation"  '^^^^^[^'^teristic  for  which  Japan  is  famous.  Author 
Ezra  Vogel  says  jFis  probably  the  most  important  single  element  in 
Japan's  continuing  economic  succes^^Sr^ 

American  executives  feel  the  need  to  make  informed,  competitive 
decisions. 

IS  is  a  logical  sek»4^  to  help  statisfy  that  need. 
IS  cannot  satisfy  the  need  without  a  strong  DA  function. 
For  two  centuries  executives  have  known  that  their  prosperity  comes  from  A 

r 

Natural  resources. 


Capital  equipment. 

Uhor. 

Now  executives  know  (or  at  least  sense)  that  their  competitive  position 
depends  on  another  factor:  Information.  i  <iJ 

"Data  ownership"  is  an  issue  about  whioh  INPUT  Qsk«d  respondents.  All  ffe 

ha^opinions. 
A 

The  concensus  was  well  expressed  by  a  iiiApui idmnt. who  i*  the'^^ 
director  of  a  large  information  planning  project.    He  asked 
rhetorically,  "Who  owns  the  data?  Who  is  the  custodian?  What 
is  the  user-creator  relationship?" 

.         He  added,  "This  is  not  well  understood  by  users." 
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To  top  executives,  data  ownership  is  not  an  issue.  If  PCs  and  floppies 
contain  data  that  cojjl^on tribute  to  better  higherjievel  information,  "^4^ 
the  company  owns  thos^  data.  ^ 

The  burden  of  beating  a  path  to  those^data  falls  on  DA. 

In  companies  attempting  to  "beat  a  path,"  the  almost-universal  mechanisms 
wer^ 

Policies  regarding IJ^,,^^  (Jo^'U^  oUt^U^euut^ ^ 

LEVELS  OF  DESCRIPTION 

Some  of  INPUT'S  respondents  mentioned  "executive  information  systems"  in 
addition  to  the  usual  term,  management  information  system^  (MIS^.    T+I^  r^^djt^ 
recognized  that,  compared  to  lower  and  middle  management,  top  executives 
need  information  that  is  different.  Their  information  shoulcj/\ 

Cover  a  broader  scope.  J^f\fjz 

Be  expressed  in  tl^tf  terms  «o4  concepts  wfH>wh4€h  executives.  w©f4«^  vV^y) 

MIS  specialists,  often  in  middle  management,  may  not  know  the 
executive  terms  and  concepts. 

Software  is  rarely  available  to  translate  raw  data  into  thSse 
terms  and  concepts.  ' 

Exhibit   III-6   is   a  deliberately.,  truncated,  organization  chart.  It 
illustrates  the  conceplj  itv  whtoh  dittareHt  level^f  of  management 
interested.  ^ 
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The  organization  chart  describes  a  plant  that  manufactures 
hybrid  electronic  m  i  croc  ircu  its  and  three  other  lines  of 
products.  It  also  has  engineering,  marketing,  financial,  and 
administrative  operations. 


The  first-level  supervisor  needs  answers  to  questions  such  as: 
How  many  hybrids  are  scheduled  through  my  autobonder  today? 
How  many  did  H  do  yesterday?  How  many  were  defective? 
(These  questions  will  be  used  repeatedly  as  examples  in  this 
report.) 


The  next  level  of  management  needs  more  comparative 
information,  e.g.,  of  the  30  functions  in  manufacturing  a  hybrid, 
where  do  most  defects  arise?  Which  functions  are  most 
responsible  for  our  being  behind  schedule  on  our  contract? 

Upper-middle  management  wants  to  see  higherTl'evel 
comparisons:  What  are  the  backlogs  on  our  four^product  lines? 
Is  any  product  giving  us  undue  problems  with  defects? 

Top    executives.  ^  want    information    to    justify  high-level 
decisions!     ws^  couM^et  an  automatic  handling  and  kitting 
systemjfor  hybrids/M-  w«~r  r>i.i  I  d .  g^lgy^rec  i  si  on  milling  systems 
for  inertial  products/  which  wewiggive  fcwthe  greater  return  on  Cl^^ 
investment^  If  Mol^uo^Tfoi'^oould  compete  with^t^'"e^hybrids, 
how  would  t^?^uqlity  compar^^th  our-s?  ^  ffoMlvhof 

'J  \\\ 

The  organization  chart  in  Exhibit  III-6  is  a  hierarchy.  Answers  to  questions  \^  \ 
from  different  levels  on  the  hierarchy  must  come  from  a  hierarchy  of  data. 

Exhibit  III-7  shows  such  a  data  hierarchy.  It  parallels  the  management  \/ 
hierarchy  illustrated  in  Exhibit  III-6. 
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1-  1 

Note  that  data  move^  up.  As  they  do  so,  they  lose  their  identity4-but 
not  their  influence. 


The  first-level  supervisor  wanted  to  know  how  many  defects 
were  caused  by  the  autobonder.  Such  raw  data,  by  themselves, 
are  not  needed  at  the  next  level  of  the  hierarchy. 

.         But    the   data   influence   what   the   next    level    does  need: 
information  on  comparative  quality. 

Finally,  the  data  exert  an  indirect  influence  on  the  market  share 
estimates  at  the  top  of  the  hierarchy. 

o  Such  a  data  hierarchy  shows  why  top  executives  believe  all  data  ultimately 
belong  to  the  company.  All  data,  affecting  any  company  function  could 
ultimately  influence  top  executiv^aecisions. 

o        DA's  responsibilities,  broadly  defined,  include  creating  the  basis  for  such  a 
Irarchy. 


F.       WHAT  "INFORMATION"  AAEANS 


o  Many  vague  definitions  of  data  and  information  have  been  presented,  with 
confusing  results.  The  confusion  is  not  necessary.  Data  and  information  can 
be  defined  precisely. 

o  Information  can  be  defined  mathematically:  Information  is  that  which 
reduces  uncertainty.  ("Uncertainty"  is  also  defined  mathematically,  in  terms 
of  the  horngeneity  of  a  field.) 
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One  bit  of  information  reduces  uncertainty  by  one  hal 


Suppose  a  manufacturing  supervisor  asks,  "Which  is  damaging 

^   more  partsT'^the  quloboader  or  the  pjck-and-p I  ace  machine?" 

#        The  answer  conveys  one  bit  of  information. 

Note  that  the  data  or  answer  require^  a  structure  or  question  before 
ttie^'can  convey  information.  A 

iron 

This  mathematical  definition  of  information  is  due  t«  Norbert  Weiner. 
It  has  been  used  in  information  theory  for  forty  years. 

<K 

o        Information  also  can  be  defined  in  half-mathematical,  half-psychological 
manner.  ^ 

One  of  the  first  successful  artificial  intelligence  systems,  AGILE,  was 
based  on  adapative  matrices. 

There  was  once  a  superstition  that  the  human  brain  was  smooth 
whnn  it  wm  naive,  qnq  that  it  "added  a  wrinkle"  every  time  w 
5/p)»lt^«A<^  ^MiJb  h&MM(jit  Hoarnod  somcthingp  This  superstition  happens  to  be  analogous  to 

what  really  happens  in  an  adaptive  matrix:  Before  "learning," 
the  entries  in  the  matrix  are  "smooth"  and  uniform.  After 
learning,  the  matrix  entries  are  more  varied. 

Before  AGILE  "learned,"  its  matrices  were  homogeneous,  and  it 
was  therefore  "uncertain."  As  data  were  converted  to 
information  within  AGILE,  the  entries  in  its  matrices  created 
patterns  that  reduced  "uncertainty." 

o        So,  in  terms  of  artificial  intelligence,  information  is  that  which  changes  an 
adaptive  matrix. 
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AGILE  has  been  used  in  connection  with  adaptive  matrices  for  twenty 
years. 

Infornnation  can  be  defined  psychologically  in  sinnilar  terms:  Information  is 
that  which  changes  a  mental  "matrix." 

Of  course  a  person's  attitudes  may  prevent  the  information  from 
"getting  through"  to  make  the  change. 

Strictly  speaking,  information  is  that  which  has  the  potential  of 
changing  a  mental  matrix. 

Psychologists  havei^qg  studied  how  mental  stKJctures  affect  the 
prodtjction  of  information. 


one  sdy^,  "John  and^^ary  sdw^the  moua,tain|^flying  to 
California,"  list^n^rs^ow  that  John  and^M^ir^c^^e  flying  not 


the  mountoHTST'  ^  '  »/ 


In  short,  data  convey  information  after  they  are  processed  in  an  appropriate 
"matrix." 

Suppose  a  person  says,  "Eight  is  the  factor  by  which  we  can  speed  up 
coding  if  we  go  to  NOMAD."  Or  another  says,  "Thirty-seven  was  the 
number  of  defects  from  the  autobonder." 

"Eight"  is  a  datum  that  conveys  little  information  if  it  does  not 
go  to  a  mind  that  knows  what  NOMAD  is,  and  what  the 
alternative  is. 

"Thirty-seven"  gives  little  information  to  a  "matrix"  that  does 
not  have  a  "structure"  representing  autobonders. 
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Exhibit  III-8  shows  the  analogy  between^^  i^^ 

AGILE,   in  which  data  vectors  and  nriatrices  are  literally 
multiplied  as  information  is  relayed. 

People, j^whom  data  are  "pi utiejAcd"  a&-4hc  people  try4oirgtuy 

information.  '"^  i^eid^ed  • 
P 

Data,  then,  are  numbers  or  other  symbols  that  transmit  information  to 
a  compatible  "matrix." 

To  an  information  theorist,  DA's  charter  Is  to  create  compatible  matrices. 

The  problem  is  that  the  matrices  are  in  different  places.   In  the^example^ 
A  .  A 

y  thft  qutobonding  defects  and  rgtutcd  quostiong,,  information  is  carried  to  the 


top  executive  not  only  by  the  data,  but^l^  th^  ' 
Structure  of  the  shop  floor  control  program. 


Structure  of  the  material  requirements  planning  (MRP)  or 
manufacturing  resource  planning  (MRP  II)  programs. 

Structure  of  the  cost  planning  and  evolution  system. 

Structure  of  the  forecasting  and  modeling  systems. 

Structure  of  the  datqbase(s)  for  all  of  the  above. 

Documentation  on  all  of  the  above. 

And,  probably,  individuals'  memories  of  undocumented  peculiarities  in 
the  systems. 
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Parenthetically,  those  "memories  of  undocumented  peculiarities"  represent 
one  of  the  biggest  challenges  to  DA. 

Many  IS  organizations  have  some  employees  whose  job  security  is 
enhanced  by  their  unique  knowledge  of  the  intricacies  of  some 
application  system.  Ideally,  that  knowledge  should  be  in  a  "matrix" 
that  is  more  publicly  available  and  permanent  than  an  employee's  mind. 

DA  can  strive  to  minimize  these  "undocumented  peculiarities"  by: 


Strict  enforcement  of  standards,  either  manually  or 
automatically  through  a  DD. 

Moving  toward  data-orientated  development,  in  which  more 
application  programs  are  developed  with  self-documenting 
fourth-generation  languages. 


As  data  and  information  flow  to  higher  levels,  more  comparisons  must  be 
made.  For  example,  information  on  defective  company  products  must  be 
compared  with  comparable  information  about  the  competitors'  products.  This 
information  (provided  by  the  marketing  department  or  a  consultant  such  as 
INPUT)  will  be  in  ordinary  English.  This  may  not  be  immediately  comparable 
to  the  IS  reports. 

It  is  not  surprising  that  most  DA  managers  have  found  it  more  rewarding  to 
concentrate  on  serving  (and  controlling)  their  DP  community,  rather  than  on 
trying  to  serve  the  top  executive  directly.  ^ 


One  should  not  apologize  for  serving  the  lower  levels.  They  indirectly 
serve  the  top. 
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o        Nevertheless,  the  trend  is  toward  IS  and  DA  directly  serving  higher  and  higher 
levels  of  the  organization.    This  is  illustrated  in  Exhibit  III-9,  in  which  a 
classic  organization  pyrannid  is  superimposed  on  the  DA  maturity  scale  of-  IS^ 
^fnaturity  depicted  in  Exhibit  111'*^'^ 

^\  ' 

\^ 

G.      PRESSURES  FOR  -REGARPtN^CENrTRALIZATION 


o        One  of  INPUT'S  respondents  defined  DA  in  these  terms: 

"At  the  corporate  level,  create  and  maintain  a  data  model  of  the 
enterprise."  r 

"Manage  the  tools  to  support  the  data  model." 

"Manage  the  tools  to  cause  the  data  structure  to  conform  to  the 
model." 

o        In  this  definition,  DA  is  a  highly  centralized  function.    There  are  strong 
arguments  for  such  ^Qntr^li^nti"nj;.nnd  fnr  strength  t"  jn  with  iti( 


yJr  would  satisfy  the  chief  executive's  mdicated  in  Exhibit  \U^r>i/^ii 

Assuming^  the  discipline  and  '^ools  to  cause  the  data  structure  to 
conform"  were  strong  enough,^|^oul^^ 

.         Reduce  the  black  market  in  questionable  data. 

.         Let  users  take  advantage  of  PCs,  fourth^eneration  languages 
(f^Ls),  and  DSGsr  J/IjUU^  ^Ou^^^iO^se^  Ct>SS^  , 

& 
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^  /ncrease  the  ability  and  speed  of  the  corporation  in  responding  to  quick 
questions  from  the  customers  or  government. 


'°A 


There  are  also  practical  pressures  against  centralizat 

Creation  of  the  data  model  can  be  an  enormous  job,  a  costly 
investment  with  delayed  and  uncertain  pa^^ffs. 

Any  centralized  function  may  fail  to  be  responsive  to  the  needs  of  its 
more  remote  users. 

There  is  a  trend  toward  decentralization  of  computing/  DA  goes  against 
this  trend.  /\ 

Consensus  opinons  of  INPUT'S  respondents  were: 

"There's  value  in  the  concept.  But,  is  it  ever  really  achieved?  It's  an 
overwhelming  task  to  set  up." 

"It's  a  lot  of  work,  a  lot  of  effort.  It  makes  sense  on  a  conceptual 
level,  but  it  needs  to  be  converted  to  practice.  We  need  more  practical 
experience." 

"I'm  not  sure  I  see  a  DA  process  that  is  a  central  management  of  all  the 
data.  Does  a  central  facility  clog  the  flow?" 


INPUT  concludes  that  centralized  DA  is  needed,  but  only  after  the  enterprise 
it  serves  has  been  defined.  This  definition  is  the  main  subject  of  Chapter  V. 
The  next  chapter  mcluifas'  the  centralization  issue  in  a  review  of  DA  theory 
and  ae+cra?results. 
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IV      pA"THEORY  AND  EXPERIENCE 


THE  INFRASTRUCTURE  ARGUAAENT 


BACKGROUND  AND  SYMPTOMS 


o  The  1970s  saw  significant  developments  in  both  programming  and  datapase 
technologies.  1 

Large-scale  date  base  technology  came  of  age. 

So  did  structured  programming. 

Large-scale  magnetic  data  storage  media  were  already  available. 

o  What  did  these  technologies  produce?  General ly,^"islands  of  technology^on 
which  each  application  "did  its  own  thing"  without  real  coordination  or 
integration  with  the  others. 

o  In  such  a  situation,  it  is  hard  to  integrate  information  from  one  source  with 
information  from  another  source. 

To  service  information  requests  from  the  management  and  executive 
levels,  IS  typically  has  to  access  several  application  databases  and 
synthesize  the  results  (ns  illiistrntod  in  Exhibit  III  1)* — * —  rff 
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The^  synthesis  requires  expensive  and  slow  "bridge-building"  operations 
between  the  application  islands. 

Meantinne,  new  versions  of  the  request  are  likely  to  arrive  as 
managennent  receives  the  first  answers,  does  not  like  them,  and  re- 
thinks its  questions. 


Thus  it  is  difficult  for  IS  to  answer  high-level  questions. 

Lack  of  integration  produces  a  long  list  of  additional  symptonns  of  an 
underlying  lack  of  integratiory;\ 

Poor/ or  inconsistent/ data  qualit)^leading  to  unreliable  information. 

Inability  to  combine  data  into  new  information  structures  without  first 
changing  datc^ase  definitions  or  programs. 

Data  redundancy. 

Frequent  failure  to  find  data. 

Inability  to  share  data  without  manually  transcribing  or  transforming 
them. 

Poor  data  security. 

Unsatisfactory  computer  performance. 
Long  search  times. 

Slow  response  times  at  individual  workstations. 
Poor  management  of  the  growth  of  computer  usa*^. 
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Visible  project  backlogs. 


Unconstrained  introduction  of  PCs  into  the  workplace. 


Escalating  cost  of  providing  the  computer  power  for  existing 
applications,  especially  in  maintenance,  \^re  most  of  the  requests  for 
change  are  serviced. 

Rising  discontent  with  the  effectiveness  of  computing  support  provided 
to  the  enterprise  as  a  whole. 


Of  course^ack  of  integration  is  not  the  only  possible  cause  of  such 
complaints.  But  it  is  a  factor.  And  IS  management  (as  surveyed  by  INPUT) 
unanimously  advocates  some  kind  of  ovei^ll  strategy  or  mechanism  for  swift 
communication  between  the  "islands." 

/ 

The  highest/priority  targets  of  integration  strategies  are: 

Data  integrability. 

Data  quality. 

Data  accessibility. 
JUSTIFICATION  SKEWING 

One  INPUT  respondent  pointed  out  a  frequent  difficulty:  jZ^ne  might  like  to 
automate  a  small  manual  function,  but  the  automation  might  not  be  feasible 
because  of  the  changes  that  would  have  to  be  made  in  dat^ases. 

For  example,  a  health  maintenance  organization  is  expanding  to  dental 
services,  and  it  wants  to  automate  a  special  credit  check  on  patients 
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receiving  major  dental  treatments.  The  programming  is  simple.  The 
problem  is  that  a  customer  number  would  have  to  be  changed,  and  this 
would  entail  changes  in  35  databases.  This  is  too  much  work. 
Furthermore,  there  is  a  danger  tharriot  all>affeec±edL  datcpases  will  be 
changed.  ^K^^^^S^  ^ 

The  general  situation  is  this:^^j<:^cking  DA,  dat^ases  are  not 
integrated;  ao^^small  enhancements  are  likely  to  caiise  big  fan-out 
problems  in  maintenance. 

The  result  is  what  the. respondent  called  "justification  skewing." 

Large  improvements  might  make  sense,  but  th^  are  infrequent  simply 
because  they  are  expensive.  ^ 

I  ^^11 1  he'  improvements  are  not  mad^;  because  the  fan-out  problems 
outweigh  the  advantage^ 

INFRASTRUCTURE  ANALOGIES 

There  is  an  analogy  between  phone  and  electric  companies  and  integrated 
databases. 


f  the  phone  company,^  deciding  whether  to  develop  automated 
equipment]  had  tried  to  justif^^j+43ji«vejj3[j^^  for  single  station,  we'd 
still  be  going  through  operators  for  all  of  our  phone  calls. 


If  the  electric  power  companies  had  tried  to  justify  a  network  of  power 
lines  on  the  basis  of  a  single  home  or  business,  we'd  all  still  be  using 
candles  and  kerosene  lamps. 


if  large  IS  departments  look  for  single  applications  to  justify  the 
development  of  integrated  datdbases,  tho^y  will  nolj^evelop  theTsHj_^_^ 
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I 

o        An  integrated  dato^ase,  then,  is  like  a  network  of  power  lines  or  telephones: 
n\  is  an  infrastructure.  i 


y'lpplirntirm-jiknnwn  to  hr  nrrrlnd^nny  be  built  on  /tT  ^ 
ApplicationsJ'^discovered  to  be  needed  in  the  future  may  be  built  on 


with  today's  technology.  J(^>y^ 


As  new  technologies  develop,  the-infrastructure  may  support  appliea^— 
tnjiis  Itiul  urti  r^ot  now  c<3riLeiveU.- 

B.       LOGICAL  APPLICATIONS  OF  THE  INFRASTRUCTURE 

^  f  r  ^ 

o        Strong  logical  arguments  can  be  made  thcrh-pny/nffin  would  iciult  fronrr «nr^ 
infrastructure^.^i'''^'^^^^'  ^'i^'^^^^l  v^fv^j^i'C'fitX^^^'^ 

o        Most    fundamentally,   Ahe    infrastructure    would    foster    "data-oriented  j 
devel  opment"  /</s  lOppI  icati  on-oriented  development,"  as  illustrated  in  Exhibit     \  V 


IV-I.  v^-^-^  1^ 

—  The  data  orientation  builds  on  a  solid  foundation  of  data. 

r 


r 


The  application  orientation  builds  on  the  logic  of  the  program, 
which  is  "floating"  and  must  trap  data. 

■Au  indicuitid  in  Iho  example  of  the  dontal  credit  chooU,  the  cost 
of  trapping  the  data  can  be  prohibitive.  (Gcs  Cectiun  AI2  uT  lliia^ 
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PAYERS  TO  ISLAND  END  USERS 

^nd  users  would  find  it  easier  to  use  FGLs  and  DSSs/ because  the  data  to  feed 
them  would  be  easier  to  find  and  use. 

IS  would  find  it  easier  to  maintain  existing  application  programs. 


Many  application  enhancements  affect  datcpases.  With  morejj 
integrated  datcpases,  these  enhancements  would  be  easier  to  make. 


t(^a 


As  datcfoases  are  changed  (e.g.,  in  going  from  a  ZIP  code  to  ZIP  +  4), 
application  programs  have  to  be  changed.  With  the  support  of  a  strong 
DA  function,  the  datcpases  would  be  more  expandjble  and  more  capable 
of  transmitting  such  changes  to  the  application  programs. 

Problems  with  redundant  data  would  be  lessened. 

Storage  costs  would  be  cut. 

Maintenance  work  would  be  lower. 

Security  would  be  easier  to  accomplish. 

Most  important,  currency  and  version  problems  would  be  minimized. 

IS  would  find  it  easier  to  develop  new  application  systems,  because  they  would 
be  based  on  more  standard,  available  data. 

Auditability  would  be  improved. 

Manual  movement  of  data  could  be  more  easily  automated. 
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Even  in  a  manufacturing  operation,  it  is  estimated  that  12%  of  gross 
sales  is  spent  in  moving  information.  Most  of  this  movement  is 
manual.  If  half  of  the  movement  could  be  automated,  this  would 
double  the  profit  margins  of  many  companies.  Given  the  "infrastruc- 
ture" of  an  integrated  dat(^ase  system,  the  cost  of  much  of  this  auto- 
mation would  be  negligible. 

2.       PA^^FFS  TO  MANAGEMENT  AND  EXECUTIVES 

o        Data  would  carry  more  information  to  all  levels  of  management^^ 

r  

\  Less  information  would  be  lost  in  nonstandard  and  undocumented 
"matrices"  as  the  data  move  up  the  hierarchy. 

o        Data  could  be  translated  into  tactical  and  strategic  information. 

Managers  would  receive  more  understandable  information. 

Top  executives  would  have  higher-level  views  of  the  decisions  facing 
them. 


Therefore  the  quality  of  decisionHmaking  should  rise. 


C.       ACTUAL  EXPERIENCE 


o        The  DA  concept  is  only  a  few  years  old.  But  implementation  of  the  concept  is 
«(^l  ow.proccsa.  • — *- 

A 

Carol  Shulman,  director  of  marketing  for  Database  Design,  Inc.,  says, 
"It  takes  several  years  of  orchestrated  development  to  achieve  shared, 
nonredundant,  stable  databases." 
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While  a  small  manufacturing  facility  built  a  single  shared  database  in 
about  two  years,  a  large  aerospace  corporation  plans  to  spend  five 
years  in  creating  a  set  o^  large,  shared  date  bases. 


As  a  result  of  the  youth  of  the  DA  concept  and  the  length  of  time  it  takes  to 
reach  maturity,  complete  case  histories  are  almost  nonexistent.  Quoting  one 
of  INPUT'S  respondents,  "We're  just  now  on  the  brink  of  some  success  stories." 

Even  where  limited  case  histories  are  available,  dollar  savings  are  hard  to 
quantify. 

DA  offers  avoidance  of  future  costs,  but  it  is  hard  to  say  what  future 
costs  would  have  been  without  DA. 

.         Business  conditions  and  labor  rates  change. 

Technology  changes:  New  software  tools  and  different  hardware 
become  available. 


In  short,  savings  have  to  be  estimated  in  terms  of  cost  avoidance 
against  6^moving  target. 


r 

Nevertheless,  some  clear  indications  of  successes  are  reported. 


J 


In  a  finance  company,  end  users  can  now  tap  an  integrated  datcpase 
and  use  FGLs  to  rapidly  generate  understandable  budget  reports. 


A  large  public  utiliti^(with  annual  sales  of  more  than  half  a  billion  dollars)  is 
about  a  third  of  the  way  through  its  schedule  to  implement  a  sophisticated 
information  resource  management  system.  It  reports  qualitative  results  and  a 
quantitative  prediction. 
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Qualitatively,  off-the-shelf  application  packages  are  now  easier  to 
install,  because  they  can  be  more  easily  integrated  with  other  business 
sytems. 


"Much"  data  redundancy  (and  the  accompanying  threats  to  data  control 
and  integrity)  are  eliminated. 

Good  data  structures  facilitate  a  higher  quality  of  application 
development. 


In  terms  of  speed,  the  quantitative  prediction  is  this:  ^ithin  three 
m^c^ years,  the  utility  will  be  developing  new  applicat1onS|J'orders  of 


magnitude"  faster  than  would  have  been  possible  in  the  past. 

Another  utility  operates  a  nuclear  power  plant.  The  Nuclear 
Regulatory  Commission  urgently  requested  engineering  drawings  from 
the  utility/soj^potential  safety  problem  could  be  analyzed.  The  utility 
had  an  integrated  datc^se  designed  in  part  to  facilitate  responding  to 
such  ad  hoc  requests.  It  was  able  to  retrieve  the  information  for  the 
drawings  rapidly.  Thus  it  avoided  a  potential  shutdown,  which  could 
have  cost  "K^i I  lions  of  dollars. 

A  manufacturing  company  developed  a  facility  for  searching  defeases 
that  had  been  separate^lt  was  able  to  identify  large  products  that  -ii—^ 

sold  in  the  past  |^+*€it.  wouldpoon  needing  replacement  parts. 
Thus  it  was  able  to  pnepuie  lu  -satisfy  its  customers  at  a  high  profit 
margin  t'©4+seffr^ 

One  of  the  nation's  largest  insurance  companies  has  been  building  a 
strong  DA  function  for  six  years.  DA  is  highly  centralized,  while  DP  is 
widely  distributed  through  more  than  a  dozen  subsidiary  companies. 
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The  DA  manager  believes  substantial  development  costs  have 
been  avoided,  but  he  cannot  estimate  them  precisely  because  of 
the  lack  of  a  stable  base  of  comparison,  and  because  of 
technical  changes  (e.g.,  new  languages,  etc.) 

An  information  center  has  been  created  and  is  working  well. 

There  are  also  reports  of  problems  in  companies  without  a  DA  function  or  an 
integrated  datcjbase  approach. 

The  vice  president  of  a  manufacturing  company  asked  for  vital  cost 
figures  on  a  product.  Three  contradictory  answers  came  back  from 
three  different  datdbases. 

Another  manufacturer  found  that  a  programmer  had  set  up  a  system  so 
that  a  customer  had  to  exist  on  a  file  before  an  order  could  be  taken yjy 
fcofti  liiil^  So,  in  the  absence  of  a  business  model  identifying  the 
information  that  should  and  should  not  be  needed,  a  programmer  was 
inadvertently  determining  company  policy  on  sales! 

Theoretical  expectations  are  compared  with  the  above  actual  experiences  in 
Exhibit  IV-2. 


D.      PROJECTS  IN  PROGRESS 


American  manufacturing  is  showing  strong,  broad  interest  in  integrated 
databases. 


The  Air  Force  is  sponsoring  Boeing  in  the  development  of  an  Integrated 
Sheet  Metal  Center  (ISMC). 
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A  major  feature  of  the  ISMC  is  a  set  of  software  tools  (to  aid  in 
design  and  management)  that  will  be  integrated  through  a 
common  data  model. 


Another  feature  is  the  integration  of  data  from  different 
dat<|()ases  to  coordinate  operations  all  across  the  factory. 

A  major  electronics  company  is  in  the  process  of  acquiring  an 
integrated  system  to  control  the  manufacture  of  microcircuits. 

A  major  automobile  manufacturer  is  dealing  with  this  problem:  How  do 
you  (tteep^ngineefij^/data  in  electronic  format  as  long  as  possible? 
How  do  get  information  from  an  engineering  datc^ase  (perhaps  on  an 
IBM  computer)  to  a  manufacturing  database  (perhaps  on  a  Hewlett- 
Packard)? 

It  is  undesirable  to  transfer  the  data  to  paper  along  the  way 
because  of  the  cost. 

Also,  the  transfer  to  paper  creates  opportunities  for  human 
error. 

Finally,  the  computer-paper-computer  route  raises  the  danger 
that  information  may  be  lost  as  the  "matrix"  changes. 

The  Air  Force  is  sponsoring  a  study  of  ways  to  solve  the  same 
problem.  McDonnell-Douglas  is  the  prime  contractor.  Results  are 
expected  to  be  applied  in  both  the  aerospace  and  commercial 
manufacturing  industries. 
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GUIDELINES:  WHO  REALLY  NEEDS  DA? 


o        This  chapter  addresses  some  vital  questions. 

Establishing  DA  is  an  effort.  What  is  the  scope  of  that  effort? 

What  is  the  enterprise  that  DA  will  serve? 

^  smallest 

What  kinds  of  enterprises  have  the  greatest  and  least  real  need*  for 
DA?  ^ 

A.      DECIDING  WHO  YOU  ARE 

o        DA  cannot  be  established  or  augmented  intelligently  until  one  Identifies  what 
or  whom  DA  serves. 

As  an  infrastructure,  DA  does  not  merely  serve  individuals.  It  serves 
communities.  These  communities  include: 

The  IS  community. 

People  doing  "consumer  computing." 

Higher  managers. 
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These  communities  form  a  larger  community  tliat  DA  serves^thot 
larger  community  is  the  "enterprise." 

One  question  is  the  key  to  identifying  the  memberi^l^>A*s  enterprise:  To  what 
extent  are  their  fates  entwined?         />  ^ 

Q/  ^  

/  'If  consumer  computers  and  the  IS  community  are  both  supporting  the 
same  higher  management^nd  no  one  elsejand  if  that  higher  manage- 
ment has  few  responsibilities  that  do  not  concern  the  IS  community  and 
end  users,  then  all  of  their  fates  are  entwined. 

if  people's  fates  are  entwined,  then  they  ore  economically  integrated. 

The  hallmark  of  DA  is  integration,  and  it  should  serve  an  integrated 
enterprise.  Before  trying  to  establish  or  strengthen  DA,  one  should  define 
that  enterprise. 

The  enterprise  certainly  need  not  be  a  profit  and  loss  center.  Typically  it  is 
just  a  well-defined  operation  within  a  corporation. 

As  a  practical  matter,  one  should  normally  define  the  enterprise  to  balance 
three  criteria: 

The  enterprise  should  be  as  integrated  as  possible.  It  should  make 
economic  sense. 


It  may  have  to  include  DA's  existing  responsibilities:  DA  ppobgbly  will 
not  have  carte  blanche  to  redraw  the-ffxip.any  way  it^ploasps. 

— y—  ^ 

The  enterprise  should  be  small  enough  to  be  tractable  but  large  enough 
to  justify  the  investment  in  the  infrastructure. 
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As  a  rough  rule  of  thumb,  an  enterprise  using  an  HP-3000  or  larger 
computer  is  large  enough  to  justify  the  investment. 

o        If  it  is  "above  critical  mass"  economically,  a  small  enterprise  is  preferable 
because: 


in  front/en 


Investments  in  front^nd  analysis  are  minimized. 
DA  has  a  chance  to  learn. 

DA  has  a  chance  to  prove  its  value  before  expanding, 
o        In  summary,  DA  should  seek  first  to  serve  a  small  interdependent  enterprise. 

B.       CRITERIA  FOR  NEED 

o        The  degree  to  which  an  enterprise  needs  DA  is  a  function  of  several  criteria: 
The  volatility  of  the  enterprise. 
Its  size. 

Its  interactivity. 
Its  data  orientation. 
1.  VOLATILITY 

o        After  deregulation,  banks  and  airlines  need  DA  more  than  they  did  before. 
Their  databases  are  changing  more  rapidly. 


ir  datqba 

I 
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Fare  structure^routes,  for  example,  are  changed  more  quickly  because 
deregulation  allows  competitors  to  change  those  variables  on  almost  a 
whimsical  basis.  i 

->  ^ 

Interest  rates  charged  and  paid/types  of  loans/ are  subject  to  greater 
change  because  the  competition  is  freer. 

Such  changes  increase  the  need  for  flexible,  expoBsiUle  databases. 
In  general,  1+»e^he  more  volatile  the  enterprise,  the  more  it  needs  DA. 
SIZE 

When  more  interactions  are  needed  among  defeases,  thei^A  is  needed  more. 

The  number  of  interactions  varies  with  size.  Within  some  limits,  any 
doubling  of  the  size  of  the  enterprise  will  roughly  quadruple  the  number 
of  necessary  interactions. 

Also,  as  size  increases,  human  memories  and  personal  acquaintances 
become  poorer  and  poorer  substitutes  for  a  DD. 

In  the  organizations  surveyed  by  INPUT,  the  larger  ones  tended  to  have 
more  mature  DA  functions. 

In  general,  then,  the  larger  the  enterprise,  the  more  it  needs  DA. 

But  at  some  pointythis  need  is  balanced  by  the  practical  advantages  of  dealing 
with  a  small  enterprise. 
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INTERACTIVITY 


Some  organizations  inherently  have  nnore  interactions  bHwteii  lliuii  pui 


An  example  of  an  interactive  company  is  a  firm  that  sells  computer 
systems  to  large  dental  offices. 

Training  the  customers  is  a  problem  for  the  company. 

As  application  programs  are  changed,  the  trainers  need  to  get 
information  about  the  changes. 

As  the  trainers  have  problems,  the  sales  department  needs  to 
know  about  them. 

.  The  manufacturing  department  buys  other  companies'  computers 
and  peripherals,  and  lashes  them  together  into  a  system  with  the 
firrr^own  software.  As  sales  change,  the  firm  will  buy  from 
different  hardware  suppliers. 

The  application  programming  department  needs  to  know  about 
hardware  changes. 

.         As  application  programs  change,  the  trainers  are  affected. 

A  company  in  the  same  size  range  is  an  accounting  service  firm.  But  it 
is  not  very  interactive.  It  simply  provides  clients  with  accountants  on 
an  overload  basis. 

The  more  intrinsically  interactive  companies  have  more  interactions  among 
their  databases,  and  therefore,  have  a  greater  need  for  DA. 
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DATA  ORIENTATION 

Some  companies  are  more  oriented  to  masses  of  data  than  others,  ^^f  a  parts 
distribution  company  and  a  mining  company  are  exactly  the  same  size  in 
terms  of  gross  sale^ 

The  distributorship  may  have  ten  times  as  many  employees  as  the 
mining  company. 

The  distributing  company  may  have  a  thousand  times  as  many 
customers. 

The  distributorship  therefore  would  have  a  greater  need  for  both  IS  and  DA 
than  would  the  mining  company. 

Information  is  more  strategic  for  some  companies  than  for  others: 

For  deregulated  industries,^  is  more  strategic.  |prfDTTOatioaJsj3ioi:e----Q^ 
neGessariyLlor:_tb©m-tf-they  are  mrespood-hyi  llie  cUTiipeliliuii; — ^ 

It    is   particularly  strategic   in   commercial   manufacturing,  where 
competition  is  worldwide. 

It  is  less  strategic  in  regulated  industries  and  in  natural  monopolies. 
They  cannot  use  information  to  gain  an  advantage  over  their 
competitors. 

Therefore,  in  general,  DA  is  more  valuable  to  enterprises  that: 

Are  oriented  toward  masses  of  data. 

Can  use  information  to  a  competitive  advantage. 
These  criteria  are  summarized  in  Exhibit  V- 1 . 
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VI       HOW  TO  SET  UP  OR  STRENGTHENS^ 

o  This  chapter  first/ presents  ^  description  of  how  to  establish  a  strong  and 
effective  DA  function^undef  Kl^ullzed  eondition&i-^  Then  more  realistic 
methods,-^!  ived  from  ths  ideal^re  presented. 

o        There  are  two  prerequisites  to  any  method: 

Getting  the  support  of  top  management. 

Getting  the  involvement  of  users. 

A.      THE  PREREQUISITE  STEPS  |  ^ 

I.        Getting  Top  Management  Support 

o        Some  respondents  observed  that  "Without  top  management  support,  you  don't 

really  have  DA.  You  just  have  a  G^ata  dictionary." 

/ 

* 

(xppeAri  "^5 

o  Proper  establishment  of  DA  requires  a  sequence  of  theoretical-goundiag 
work.  Without  management's  understanding  of  this  work,  support  for  it  may 
wither. 
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«lorr 
tioqquk 

9dt  lo  xx>trt0VYTf  no 


yom  xobot  eaii 
•rit 


o        To  make^^d(jr^oj*fff^s1>niat^f  >«9wrcostSy  wQllr11>rougb;ti5£<^^^  iriTfhe  meTj^a 
o4+owed».<lnd  ds+im«t^he  persorv+iours  reqitired 


^        Consulfants,  modelers,  data  designers,  etc 

f    /7 PeopJa. — represenfmg — the  ^^ential  jobs  in  the  enterprisg^-bcing-^ 
/    interviewed*  by  modelers  to  get  information  about  th^nforiiiuHrjn  they  *^ 

•        Record-keeping  support. 
0        Management  support. 

Add  the  cost  of  any  software  tools  that  are  purchased  to  aid  in  such  functions 
as  normalizing  data  models. 

<9s       Subtract  the  cost  of  any  planning  activities  that  will  be  replaced. 

The  sum  is  the  estimated  net  cost  of  establishing  DA. 

o        Or,  following  the  idea!  method^tWs^ery  rough  rule  of  thumoM  ,  , 


Tion*  • 


Estimate  the  number  of  different  kinds  of  essential,  informdtionf  ' 
handling  jobs  in  the  enterprise. 

Multiply  that  number  by  $2,000. 

Th^  product  is  the  first  rough  estimate  of  cost. 

U)^4k  mw>*<*^ )  a  ^  Q 

o      frankly  compare  therxosts  and  benef its^'th  yoisr-mjmc^Tneni. 
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GETTING  END-USER  INVOLVEMENT 


Establishing  or  strengthening  DA  requires  significant  time  and  attention  from 
end-users  for  two  reasons: 

They  are  some^^  the  most  imrnedjate  beneficiaries  of  data-oriented 
development.  ^  pi  wi^ua  'H^^Q^^qi^e^tt^make  better  use  of  their 
PCs,  DSSs,  and  FGLs. 

They  must  provide  much  of  the  requirements  information  that  DA  will 
need  in  designing  different  GkaocGO  of  uaef^ews  of  the  shared  data. 

They  will  gain  a  better  understanding  of  the  data  J'hcy  havo  ovqi 

A  A 

They  will  come  to  appreciate  the  value  of  shared  data  -  and  ask  for 
extensions  of  it. 


DA  cannot  simply  demand  the  time  of  the  end  users.  It  can: 

oTltieHJ^individually^^hat  the))k donate  sem^ime  to  DA. 


Request 

Request  m^heir  managers^hojl^jonn^  of  tho  oad  u3ero''^time  be  made 
available. 

Both  requests  should  be  made,  out  of  respect  hTboTh  The  end  users  and  their 
managers.  The  request  should  be  buttressed  with  clear  descriptions  of  the 
benefits  that         can  expect  to  receive  from  a  broader  DA  function. 


DA  and  end  users  will  be  jointly  looking  at  their  requirements,  identifying 
common  requirement^and  resolving  conflicts.  Therefore,  end  users  with  both 
interest  and  analytic  ability  should  be  the  individuals  whose  help  DA  requests. 
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B.       THE  IDEAL  AAETHOD:  PREVIEW  AND  COMPROMISES 


I.  PREVIEW 

e 

o        A  basic  concept  behind  the  ideal  method  is  the  ANSI/X3/SPARC  three-schem^ 
architecture. 

This  architecture  assumes  that  the  data  can  be  described  in  a  sigrae 
logical  or  conceptual  data  model  (CDM).  This  CDM  i^^  ^ 

Independent  of  any  external  application  of  the  data. 

Independent  of  any  physical  storage  of  the  data. 

Plural  user  views,  showing  how  to  tap  available  data,  can  be  mapped 
onto  the  CDM.  (These  are  frequently  called  external  data  models.) 


•^3ses,  in 


Plural  designs  for  integrated  databases,  in  the  physical  storage  media, 
can  be  mapped  to  the  CDM.  (These  are  frequently  called  internal  data 
models.) 

An  illustration  of  the  three-schem^  architecture,  with  notes  on  DA  and 
DBA,  is  reproduced  in  Exhibit  VI- 1. 

o        The  ideal  method,  in  essence,  consists  of: 

Identifying  the  functions  of  the  enterprise  to  create  a  "business  mode" 

n 

of  the  enterprise. 

Organizing  the  information  in  the  business  model  to  produce  a 
"normalized"  CDM. 
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Generating  and  documenting  user  views  of  the  CDM. 

Generating  and  docunnenting  physical  views  of  the  CDM. 

Using  a  DBMS-DD  team  to 

.         Provide  users  with  easy  access  to  data. 

Protect  data  integrity,  security,  etc. 

These  activities,  decribed  in  more  detail  in  Section  C  below,  are  summarized 
in  Exhibit  Vl-2. 

EVIDENCE  AND  CONFLICTS 

Evidence  regarding  the  value  of  the  ideal  method  came  from: 
DA  managers  interviewed  by  INPUT.^ 
.         Descrifemg- what  worked  for  them. 

,         Describmg  what  they  would  like  to  do/or  like  to  have  done. 

The  published  literature. 

Academicians  and  researchers  in  DA. 

The  ideal  method  conflicts  with  the  recommendations  of  some  of  the  vendors 
and  consultants. 

Some  vendors  bypass  the  business  modeling  step. 
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They  start  with  user  views,  then  advocate  that  buy  their 
tools  to  synthesize  *^©se  views  into  a  conceptual  data  base. 

There  is  a  subtle  danger  in  bypassing  the  business  modeling  step: 

Existing  user  views  probably  do  not  represent  all  the  uses  that 
should  be  made  of  the  corporate  data  resources.  (For  a  manu- 
facturing company  cited  in  Chapter  IV,  identifying  markets  for 
replacement  parts  was  an  example  of  these  new  uses  of  the  data 
resources.) 


To  the  extent  that  profitable  new  uses  are  hidden,  DA  fails  to 
live  up  to  its  strongest  charter. 


COMPROMISES 


Realistically,  data  administrators  may  not  be  able  to  get  the  authority  to 
follow  the  ideal  method  with  their  entire  enterprise. 

You  can  make  at  least  three  kinds  of  compromises  with  the  ideal. 


First,  remember  that  .there  was  no  plan  to  do  a  data  model  of  the  whole 
corporation)4rjust  a  ^ell-defined  enterprise  within  the  "whale."  >«  DA 
can  try  to  c?rve  out  a  smaller  organ  from  the  enterprise)*  and,  as  a 
demonstration,  apply  the  ideal  method  to  it.  , 

If  there  is  a  DSS  center  set  offuser^s/FG^^tart  by 

trying  to  serve  them.  This  would  prove  tHe  value  of  the  DA 
concept  to  end  users. 

It  would  also  give  you  an  indication  of  the  magnitude  of  the 
implementation  difficulties. 
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Any  incremental  approach  has  the  nnerit  of  avoiding  massive 
conversions,  which  no  one  wants  to  undertake  until  they  are  absolutely 
necessary. 


Second,  pressure  for  more  automated  enforcement  of  standards  may  be 
built  up  by  concentrating  on  what  one  consultant  called  "the  biggest 
failure  of  DPf: Lack  of  discipline,  rigor,  and  standards. 

Third,  the  data  administrator  can  fall  back  on  one  of  the  less-than- 
ideal  methods  described  in  Section  VI  D  and  E. 


J 


C.       THE  IDEAL  METHOD;:  SPECIFIC  ACTIVITIES 


The  activities  described  below  will  §restl)t  overlap  coch  other/both  logically 
and  in  tirr>«.' 'They  are  separated  below  in  a  way  whlsb^gives  maximum  clarity* 


of  oxplanationuJ^ 
GET  A  METHODOLOGY 


A  business/information  modeling  methodology  will  be  a  way  of  developing  a 
business  model  that  will  influence  the  data  model  that  will  inf luonee*  the 
quality  of  the  database. 

The  choice  of  methodology  will  be  influenced  by  the  way  enterprise  is  viewed 
and  can  be  perceived  0.% ^/*\ 

(Ki  Conventional  structure,  as  in  Exhibit  VI-3/or  ao  a^.. 

4*  System/^ontributing  to  t+s^conomic  or  social  environment,^^nd 
feeding  off  ^that  environmentf^s  illustrated  in  Exhibit  VI-4.  ^  ^ 
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o        Neither  view  is  wrong.  The  two  views  are  just  different  perspectives  of  the 
same  enterprise. 


To  the  extent  that  your  organization  is  viewed  as  a  structure,  it  will  be 
comfortable  to  use  methodologies  that: 

Emphasize  planning  for  the  database  systems  rather  than 
prototyp«§^  them.  v 
^ ' - 

.         Are  compatible  with  functional  decomposition  of  requirements^--^-" 
and  emphasiz^  traceability  y^/f^equirementT)  (to  know  what 
software  to  change  if  business  requirements  change). 

 ^  y 

Most   methodologies  s«ppui  I    lite'  view  ef  the   organization   as  a 

structure,  but  are  also  compatible  witf^organization-as-a-system  vfeWT 

Prominent  examples  include  lBM's_Business  Systems  Planning 
(BSP)  and  James  Martin's((Database  Design,  lnc.)pata  PlanneKj  ^  ^ 


There  are  many  others. 

To  the  extent  that  an  organization  is  viewed  as  a  system,  T^may  feel 
more  at  home  using  methodologies  that: 

^+ 

.         Emphasize  database  prototyping. 

Are  relatively  simple  and  flexible. 

For  an  analysis  of  planning  methodologies,  see  INPUT'S  FepOrtiZi^ 
Integrating  Systems  and  Corporate  Planning,  (March,  1 984). 
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Even  if  consultants  guide  the  nriodeljbuilding,  IS  and  user  personnel  will  have 
to  work  closely  with  them.  "So  j_mportant  criteria  in  selecting  methodologies 
are  the  degrees  to  which  people: 


■4^1 


Gqn  eemo  tor  understand  the  methodologies. 
Feel  they  are  realistic  Hr-yeuc  environment. 


The  world  has  methodologies  for  everything  from  designing  databases  to 
cooking  eggplants.  Even  '"^^"^  ^j'Jfi^^S^'^^^'^^"*  methodologies  start  from 
different  points  of  departure.  They  may  be  based  on: 

Describing  the  enterprise  and  the  data  it  needs  ipt^its  "Operations-^ 
(business  modeling). 

Reorganizing  the  data  in  homogeneous  clusters  (information  modeling). 

Designing  sof twar^te-*t*M e  llie  duld,  yi'ich-kLiL 

V   Use  the  data. 

Apkt  identify  what  <ota  data  and  functions  become  obsolete  if 
requirements  change. 

From  its  point  of  departure  (or  "base"),  each  methodology  covers  a  certain 
number  (or  "range")  of  related  topics.  Different  "bases"  and  "ranges"  of 
different  methodologies  are  illustrated  in  Exhibit  VI-5. 

IBM's  BSP,  for  example,  takes  business  modeling  as  its  point  of 
departure.  It  plocG^ 

^(^trong  emphasis  on^J^rategic  objective^ 4^business  process 
model^inding  ou?  who  uses  what  data,^dentification  of  logical 
data  areas,  etc.  "fAft. 
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Less  emphasis  on  data  architecture,  derivation  of  logical  system 
structures,  etc. 

f 

No  emphasis  on  physical  database  design,  applicability  to  a 
distributed  environment,  etc. 


Other  methodologies  have  comparable  limitationsjo  thoir  rangoo/  This 
is  inevitable.  '  * 


The  subject  matter  changes  from  business  processes  and 
interactions  to  data  models  and  data  us<a«eL> 

A 

The  details  of  the  methodology  have  to  change  along  with  the 
subject. 

Note  that  the  purpose  of  any  business/information  modeling  methodology  is  to 
produce  a  model  that  is: 

Adequate  in  detail. 

Accurate. 

Clear. 

If  the  model  is  clear,  its  results  can  be  used  by  other  methodologies  as 
attention  moves  away  from  business  and  toward  data. 

The  disadvantage  of  a  change  in  methodologies  is  that  it  would  eeose* 
serrte'extra  effort  in  translation  of  results. 
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The  advantages  are: 


The  new  methodology  should  be  better  for  the  purpose  at  hand. 


You  would  not  be  trapped  Into  depending  upon  a  single 
methodology  consultant  or  vendor. 


In  summary,  INPUT  recommends  that 


Choose  a  methodology  with  which  IS  feels  comfortable. 


Demand  clear  resultsTpom  itt — 


A 


Be  willing  to  change  to  a  new  methodology  or  consultant  as  the  work 
changes/' 


RECRUIT  YOUR  TEAM 

In  practice,  this  step  will  start  shortly  before  selecting  a  methodology. 

Talk  with  different  methodologists:   your  own  (if  your  enterprise  has 

them)  and  consultants.  Decide  what  combination  of  methodologies  and 

methodologists  seem$r»«r©  appropriate  to  your  enterprise.  Not  opiy  do 
A  Affluaj-i'^ 
different  consultant^  prefer  their  own  methodologies,  but  their  .back- 

ground  areas  ofnappUea+ron  differ.  They  may  have  worked  in 


/ 


Manufacturing. 


Finance. 
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Utilities. 


Software  development. 


Academic  research 


Other  things  being  equal,  pick  a  methodologist  who  knows  your 


First,  the  business  and  its  functions. 

Later,  the  data  and  information. 

People  who  know  the  subject  being  modeled,  but  who  don't  necessarily 
know  how  to  model. 

.         First,  people  who  know  your  business. 

Then,  IS  experts. 
A  librarian  or  secretary. 


industry. 


Your  team  should  consist  o 


The  person  who  is  going  to  become  the  data  administrator. 
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Y 

Reviewers,  to  check  the  models  for  accuraqr^and  logic. 

The  IS  manager  or  sponsor  of  DA,  j^frequently  talking  with  top 
management.^explaining  what  this  foolishness  is  all  about. 

V 

3.  CREATE  A  BUSINESS  MODEL 

o  The  true  concept  of  DA  is  that  information  is  an  enterprise-wide  resource 
that  should  be  exploited  and  therefore  managed  and  controlled.  Accordingly, 
DA  requires  a  basic  understanding  of  the  very  fabric  of  the  business  and  the 
environment  in  which  it  operates. 

o        The  business  model  will  represent  that  basic  understanding. 

Business  functions  are  identified  in  clear,  concise  terms. 

"Entities,"  or  the  essential  things  in  the  enterprise,  are  then 
indentified. 

o  Exhibit  VI-6  shows  a  simplified  business  function  model  for  a  small  parts 
distribution  enterprise. 

4.  DEVELOP  A  CONCEPTUAL  DATA  MODEL  (CDM) 

/ 

o        This  stepv  •  / 

Isolates  the  entities  that  are  most  essentially  involved  in  the  functions 
in  the  business  model. 


A  customer  may  be  an  entity. 
An  order  may  be  an  entity. 
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Indicates  which  entities  have  some  kind  of  direct  relationship  with 
other  entities.  For  example: 

A  customer  places  an  order. 

inventory  satisfies  an  order. 

A  CDM  can  be  graphical,  tabular,  or  both. 

Exhibit  VI-7  shows  the  essential  beginning  of  a  CDM  for  the  small  parts 
distribution  enterprise. 

The  model  is  "conceptual"  in  that  no  consideration  has  yet  been 
given  to  physical  storage  of  the  data. 

The  labeling  in  Exhibit  VI-7  conforms  to  the  government- 
sponsored  IDEF|  language.  Because  it  is  widely  used  in 
Industrial  Modernization  Incentive  Programs  and  related 
contracts,  IDEF|  is  the  most  standard  language  for  information 
modeling. 

The  IDEF|  language  and  associated  methodologies  are  in  the 
public  domain  (available  only  to  U.S.  citizens).  Information 
about  them  may  be  obtained  from  the  Integrated  Computer  — 
Aided  Manufacturing  Program  Office,  AFWAL/MLTC,  Building 
653,  Wright  Patterson  AFB,  OH  45433. 

In  Exhibit  VI-7,  the  labeling  in  the  bottom  left  corners  of  the 
entity  boxes  is  an  IDEF|  convention.  It  leaves  room  for  notation 
of  theS'attributes  above  the  entities. 

An  attribute  is  a  "value"  that  goes  with  an  entity;  e.g.,  an  order  has  a 
dollar  value,  or  inventory  holds  a  certain  number  of  entities  in  stock. 
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An  attribute's  value  may  be  a  classification;  e.g.,  the  entity 
EMPLOYEE  nnay  have  an  attribute  called  GENDER,  and  the 
"value"  of  GENDER  nnay  be  MALE  or  FEMALE. 

An  entity  typically  has  several  attributes;  e.g.,  pay  rate,  hire 
date,  gender,  etc. 

The  little  diannonds  by  some  of  the  boxes  in  Exhibit  VI-7  indicate  plural 
relationships  (e.g.,  one  customer  may  place  more  than  one  order. 
Models  with  plural-to-plural  relationships  are  normally  redone  (or 
"normalized,"  as  described  below)  to  minimize  such  relationships 
(because  they  are  ambiguous). 

Exhibit  VI-8  shows  a  table  relating  the  entities  and  functions  for  the 
parts  distributor.  The  table  maps  the  functions  in  Exhibit  VI-6  onto  the 
entities  in  Exhibit  VI-7.  Such  a  table  is  called  a  "data  matrix." 

.         A  data  matrix  table  is  not  theoretically  necessary. 

.         However,  it  will  greatly  facilitate  loading  the  DD. 

Warning!  The  CDM  must  be  capable  of  growth  and  change. 

The  functions  of  the  enterprise  may  change. 

The  things  or  "mechanisms"  performing  the  function  should  change. 

The  DA  concept  should  make  it  easier  to  computerize  new 
functions. 

Robots  may  replace  people  in  manufacturing. 
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I 


Datapases  developed  by  the  CDM  approach  are  more  adaptable  to 
changes  in  mechanisnns  than  are  those  developed  by  older  approaches. 
The  CDM  does  not  intermix  the  mechanism  and  the  information. 
Therefore,  changes  in  mechanisms  will  not  effect  the  information. 


"Normalizing"  the  model  increase^  its  capacity  to  grow  and  change  without 
becoming  ineffective  or  too  awkward. 


NORMALIZE  THE  CDM 

Normalizing  the  CDM  rebuilds  it  in  terms  or  entities  that  are  usually  more 
generic.*^  <^\g)^  c^5   b^;^   fg^  ©Y^^^T^f  K^LM^ 

ight  becom^EjyjN^O^  Ti/^^j^R^^F^I^P  RAYi^ttPE.T 


mic 


The  terms  or  entities  also  tend  to  become  more  cohesive  or  homogeneous. 

Y  (—  

4        For  example,  all  entities  associated  with  EMPLOYEE  would  be  more 
directly  linked  together  in  a  normalized  CDM. 


The  structure  of  the  normalized  CDM  is  also  more  logical 


For  example,  in  a  normalized  CDM,  GENDER  could  not  exist  without  c(/^ 
employee  first  existing. 


The  normalized  CDM  is  also  more  complete  (and  therefore  looks  more 
complicated). 


Normalization  carries  strong  advantage 


Dat^ases  derived  from  normalized  models  are  more  expandable.  More 

arm 
structure. 


information  can  be  added  to  them   without  changing  their  basic 
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Logical  access  routes  are  more  apparent  and  more  limited  in  number. 


Maintenance  is  easier.    Changes  can  be  made  to  a  class  of  entities 
rather  than  to  one  entity  at  a  time. 

Searches  are  more  complete. 

As  mentioned  in  the  example  below,  ever^Jjidividual  entity  will 
hove  every  attribute  of  every  member  of  hts  class  of  entities. 

This  completeness  of  attributes  jnsures  that  searches/  on  the 
basi^  of  attributes^re  complete. 

o        There  are  different  degrees  of  normalization. 

Each  degree  "buys"  more  of  the  above  advantages,  but  costs  more  i*^ 

...  ^ 
design  time. 

These  degrees  are  measured  in  "normal  forms." 

.         Because  future  expansion  needs  are  hard  to  predict,  it  is 
difficult  to  say  what  degree  of  normalization  a  CDM  will  need. 

Different  consultants  advocate  everything  from  the  second  to 
the  fifth  normal  form,  and  this  has  been  satisfactory  to  its 
users.  INPUT  recommends  that  CDM  developers  plan  on  going 
to  the  third  or  fourth  normal  form. 

o  An  example  from  the  IDEF|  methodology  will  illustrate  what  happens  to  a 
model  as  it  goes  through  repeated  iterations.  (These  accomplish  the 
equivalent  of  normalizing  the  model.) 
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VI' 


Exhibit  Vi-9  shows  an  early-stage  iDEF|  model  of  a  payroll  system. 

No  attributes  (like  GENDER)  have  been  entered  in  the  entity 
boxes. 


However,  the  modeler  has  decided  that  OVERTIME  is  an  entity 
in  its  own  right,  and  not  an  attribute  of  TIMECARD  or 
EMPLOYEE. 

.         The  reason  is  that,  for  every  class  of  entities  (e.g.,  employees). 

there  should  be  a  class  of  attributes  (e.g.,  oyer±ime)j  and  i^^^ 
individual  entity  (i.e.,  "entity  value"  or  "type")  shouTHTiave  every 
attribute;  but  not  all  employees  are  paid  overtime  (i.e.,  salaried 
employees  are  not). 

Exhibit  VI- 10  shows  an  expansion  of  the  model  to  include  the  various 
accounts  to  which  time  is  charged. 


f  ^This^  model  is  "nonspecific"  because  it  includes  a  "many-to- 
many"  relationship:  Many  timecards  may  show  the  same 
account,  and  many  accounts  may  be  shown  on  the  same 
timecard. 

Exhibit  Vi-I  I  shows  the  removal  of  the  nonspecific  relationship. 

Each  timecard  may  display  many  charge  numbers  (or  maybe  just 
one). 

Each  account  appears  as  many  charge  numbers. 


The  new  entity  CHARGE  connects  timecards  with  accounts. 
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Now  the  modeler  decides  to  add  entities  whose  existence  depends  on 
the  CHARGE.  That  is,  OVERTIME  and  REGULAR  TIME  could  not 
exist  if  CHARGE  did  not  exist.  The  resulting  model  appears  in  Exhibit 
VI- 1 2. 


"Dependencies"  are  marked  by  the  heavy  arrows  embedded  in 
some  of  the  lines  in  Exhibits  VI-9  through  Vi-12. 

Identification  of  dependencies  helps  generate  generic  entities 
such  as  EMPLOYEEjCLASS  rather  than  HOURLY^EMPLOYEE, 
and  PAyJtIME  rather  than  VACATIOnTpAY. 

As  the  configuration  of  entities  begins  to  stabilize,  classes  of 
attributes  are  added  to  the  boxes.  Additions  are  shown  in  Exhibit  VI- 
13. 


Also,  dependent  entities  are  examined  to  see  if  they  are  really 
attributes.  In  Exhibit  VI- 1 3,  WORKWEEK  turns  out  to  be  an  attribute 
of  EMPLOYEE  becausey{\  1^ 

WORK  WEEK  must  exist  for  each  EMPLOYEE. 

.         No  employee  can  simultaneously  have  two  work  iveeks 


OVERTIME  and  REGULAR  TIME  remain  entities  because  they 
carry  other  attributes  (i.e.,  HOURS  and  RATE)  that  could  not  be 
represented  if  OVERTIME  and  REGULAR  TIME  were  attributes. 

The  data  in  all  of  the  attribute  classes  can  convey  useful  information 
(e.g.,  pay  rates). 

Some  attribute  classes  convey  other  information.  They  are  "key 
classes." 
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They  are  sufficient  to  identify  entities. 

For  example,  NAME  might  not  be  sufficient  to  identify  an 
employee.  (There  might  be  two  Mary  Jones.)  But  EMPLOYEE 
NUMBER  would  uniquely  identify  any  member  of  the  class  of  all 
employees  of  the  enterprise. 

If  an  attribute  Is  a  key  class,  it  is  underlined  in  the  IDEF|  language. 
This  is  illustrated  in  Exhibit  VI-14. 

Key  classes  "migrate"  down.  Dependent  entities  must  have  the  key 
class  of  the  "parent"  entity. 

For  example,  in  Exhibit  VI-14,  TIMECARD  is  dependent  on 
EMPLOYEE  for  its  existence,  and  TIMECARD  must,  like  its 
"parent,"  be  identified  by  EMPLOYEE  NUMBER. 

Key  classes  also  migrate  as  ordinary  attributes.  For  example, 
DEPT  #  becomes  a  nor^key  attribute  of  each  employee  in  that 
department. 

Finally,  synonyms  and  local  definitions  may  be  added  to  the  model  by 
"tags."  For  example,  Exhibit  VI- 15  shows  that^x 


SOURCE  CODE  is  sometimes  used  as  a  synonym  for  DEPT  #. 
In  some  parts  of  the  enterprise,  ACCOUNT  #  is  called  CHARGE 


Such  tags  will  later  become  important  parts  of  the  data 
dictionary. 
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Exhibits  Vl-9  through  Vi-15  indicate  that  building  a  large  normalized  data 
model  would  be  a  lot  of  work.  This  is  true. 

An  early  decision  should  be  made:^\^hether  to  buy  software  tools  to  aid  in 
building  and  normalizing  the  models.  INPUT'S  recommendation  is: 

Get  an  estimate^rom  you^own  experts  and/or  consul  tan tg/ of  the  time 
needed  to  build  and  normalize  the  model  of  your  enterprise.  Include: 


.         The  time  of  the  experts  and  consultants. 

The  time  of  other  personnel. 

If  the  value  of  the  time  is  more  than  $30,000,  start  shopping  for 
software  tools. 

y    (Vendors  include  Database  Design,  Inc.  and  Holland  Systems. 

GET  AND  START  LOADING  A  DATA  DICTIONARY  (DD) 

The  DD  will  serve  as  the  repository  of  all  information  about  the  enterprise's 
data  resources. 

It  will  show  the  way  to  the  data. 

It  will  provide  the  "matrix"  through  which  data  can  be  interpreted  as 
information. 

The  team  will  load  the  DD  with  (at  a  minimum)^ 
Entity/relationship/attribute  definitions. 
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Where  definitions  differ  (as  in  the  "tags"  on  an  IDEF|  model), 
the  differences  should  be  noted. 

The  English-language  parts  of  the  definitions  should  make 
business  sense  to  the  users. 

.         The  DD  should  contain  the  normalized  attributes  in  the  entity 
records. 

Entity/relationship/attribute 

These  identify  the  various  user  areas  that  have  an  interest  in  the 
entities. 

They  also  specify  the  systems,  programs,  files,  and  records  that 
use  the  data  elements. 

Application  programmers  and  other  users  should  be  able  to  see  the  definitions 
in  the  DD. 

Access  should  be  easy  for  the  user  to  accomplish. 
To  protect  the  data,  user  access  should  be  on  a  ready-only  basis. 
Note  that  vn  lllft  ideal  approach,  is  to  get  a  DD  before  acquiring  a  DBMS. 

V 

In  practice,  the  opposite  has  generally  happened. 

U  . 

■Thij  order  GlarifiGJithe  criteria.should  be  used  in  selecting  a  DD^AelK 

A  7> 

Capability  of  handling  the  definitions  (discussed  above)  and  the 
data  models  or  views  (discussed  below). 


-23-  (U-CDA-VI)  tpw  -  8/9/84 


Capability  of  providing  both  user  access  and  data  security. 


Capability  of  interacting  with  the  DBMS  (discussed  below)  

^    ^*corTr^ll  ing  use  of  the  DBMS,  rather  than  being  just  a  documentation 


system. 


Choice  of  the  DD  is  extremely  important  in  minimizing  conversion  problems. 

DDs  usually  allow  some  flexibility  in  naming  standards. 

However,  all  have  some  degree  of  structure/inflexibility  in  this 
respect. 

If  a  lot  of  money  has  been  invested  in  a  DBMS,  examine  the  vendors'  DDs 
closely  to  see  if  they  will  mesh  with  the  DBMS  with  little  conversion  work. 

In  the  ideal  approach,  compare  the  DD's  flexibility  with  the  range  of  entries 
from  your  models. 

DEVELOP  AND  DOCUMENT  INTERNAL  DATA  MODELS 

Given  the  CDM,  database  designers  can  map  out  efficient  physical  structures 
for  the  database.  These  are  the  internal  models,  or  views,  of  the  data.  They 
should  be:  v 

Shareable. 

Nonredundant. 

Independent  of  the  physical  structure  of  the  database. 

Database  Administration  (DBA)  should  be  responsible  for  the  generation  and 
maintenance  of  the  internal  models. 
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The  design  expertise  should  reside  wi  administrator 
(B&A):  2-^ 


J^^BA'will  normally  bear  the  daily,  operational  responsibilities. 


o        The  Data  Administrator's  c(rganization  (B^<5^hould  be  responsible  for  docu- 
mentation of  the  internal  models. 

DA  should  be  exercising  a  regulatory  and  control  function. 

DA  should  have  control  of  the  DD. 

8.  DEVELOP  AND  DOCUMENT  EXTERNAL  DATA  MODELS 

o        These  will  provide  individual  program  or  user  views  of  the  data  for: 
Data  maintenance. 
Information  retrieval,  via 

Appropriate  access  paths. 

Special  query  and  similar  languages. 

9.  GET  A  DBMS 

o        The  DBMS  is  the  me9hanism  for  converting  the  internal  and  external  data 
models  into  a  usable 

The  selected  DBMS  should  be  capable  of  handling  the  size  and 
complexity  of  those  models. 
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It  should  also  provide  access  paths  to  the  data  element  definitions  in 
the  DD. 

o  The  DBMS  must  be  compatible  with  an  "active"  DD;  i.e.,  the  DBMS  must 
obtain  its  definitions  from  the  DD.  This  arrangemen^^ 

Reduces  labor  in  maintaining  definitions. 

Automaticaj^  enforces  naming  conventions  and  other  standards. 

o  The  DA  concept  requires  basic  units  of  shareable  data.  These,  as  provided  by 
the  DD  and  DBMS,  are  the  accessible  entity  records.  These  record^^y 

Represent  homogeneous  subdivisions  of  data  definwg  specific  subjects 

A 

of  interest  to  different  people  in  the  enterprise. 

Will  be  in  a  normalized  form,  to  improve  shareability. 

o  Homogeneous,  normalized  data  records  provide  a  pure,  solid  foundation  for 
developing  higher  levels  of  information  for  moving  up  the  pyramid  illustrated 
in  Exhibit  III-9. 

D.      THE  EVOLUTIONARY  APPROACH 


In  the  absence  of  at  least  a  test  version  of  the  ideal  method,  a  more  "natural" 
or  "evolutionary"  approach  is  recommended.  The  Data  Administrator  should 
try  to  guide  the  evolution  through  four  stages: 

Initiation. 
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Expansion. 


Fornnalization. 
Maturity. 

The  administrators  should  decide  where  they  are  on  this  evolutionary  scale, 
and  then  try  to  strengthen  their  position  f  ronn  that  point. 

Typically,  a  DBMS  is  already  in  place  in  the  enterprise. 

INITIATION 

Data  Administrator    in  this  phase,  they  shoul 

Seek  maximum  commitment  from  top  management,  as  discussed  in  the 
beginning  of  this  chapter. 

Establish  a  charter  for  DA,  using  as  strong  a  definition  (from  Chapter 
III)  as  possible. 

Select  and  install  a  DD.  Plan  to  make  a  control  mechanism  (as 
described  in  the  ideal  method)  as  soon  as  possible. 

•=-  Pluy  u  weak  police 

EXPANSION 

In  the  expansion  phase,  the  administrator  should  seek  additional  line  responsi- 
bilities, including: 

An  active  role  in  file  and  database  design. 

V 
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Direct  control  over  the  DD,  including 
Security. 

Defining  data,  etc. 
Documentation  of  more  systems  in  the  DD. 
FORMALIZATION 

In  this  stage,  the  Data  Administrator  should  sedrt^entraliza  under  DAJf\ 


;^under  DA/.*| 


Data  definition  authority. 

Dat(^<ise  design  expertise. 

*Point  out  ihcrt^n  a  large  compan)^fiHs  logical  ^o^^ 

DA  to  become  a  department  in  face  and  in  name. 

DA  to  acquire  more  formal  management  controls. 

More  application  systems  and  databases  to  be  brought  under  DD  service 
and  control.  I 


A 


By  this  time  it  should  be  possible  to  demonstrate  clearly; 
The  lack  of  a  long-range  systems  architecture. 


The  need  for  a  global  system  based  on  a  unifying  concept  such  as  the 
three-schem|i  architecture. 

e 
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4.  MATURITY 
o        In  the  maturity  stage/; 

Many  of  the  master  files  and  datc[bases  used  in  the  enterprise  are 
documented  in  the  DD. 

So  are  most  data  element^  itmt,  »^  wA^Ji 

9       ATrchswm^v^lThave  been  established  as  standard  definitions, 
o        Now  Data  Administration  carj^\^ 

Continue  the  above  documentation  and  standardization  of  definitions. 

Cooperate  in  the  development  of  hierarchies  of  information  that  will 
satisfy  top  management. 

E.      THE  DATA  DICTIONARY  APPROACH 

o        This  is  the  most  common  and  least  desirable  approach. 

o        It  typically  develops  through  these  steps: 

An  organization  starts  using  dat^ase  concepts,  and  probably  a  DBMS. 

Th^  organization  realizes  it  is  not  fully  exploiting  the  potential  of 
database  systems.  It  sees  a  lack  of: 

Standards  regarding  data. 
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» 


I  ■  - 


Control  and  planning  of  data  in  general. 


In  an  attempt  to  induce  standardization,  a  DD  is  brought  in. 

The  DD  is  used  merely  as  a  cataloging  tool.  But  the  cataloging  does 
not  produce  desirable  results. 

The  DD  is  not  actively  coupled  to  the  DBMS. 


There  is  no  CDM  to  unify  the  data  as  a  manageable  resource^  i.e.,  there 
is  no  organizing  mechanism,  and  the  result  is  a  mess.  / 

In  this  situation,  the  DA  manager  has  at  least  two  choices: 

V/ 

Move  into  theJnitiation  phase  of  the  evolutionary  approach,  and  start 
to  use  the  DD  as  a  control  mechanism. 

Define  an  enterprise  and  advocate  the  ideal  approach  bo  ■asod  tn  it. 

In  any  case,  the  ©A  must  realize  that  the^ataloging  and  other  problowc  are 
evidence  of  a  bad  approach.  It  is  as  if  one  were  creating  an  ordinary 
dictionary  for  which  an  alphabet  had  not  yet  been  invented. 


F.       LOCATION  OF  BA-  IN  THE  COMPANY 


o        Where  should  DA  fit  within  the  organizational  structure  of  the  company? 
There        a  general  consensus  on  these  points: 
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Perhaps  DA  should  report  to  the  same  person  to  whom  the  head  of  DP 
reports,  but  DA  should  not  be  subservient  to  System  Development  or 
part  of  IS.  The  goals  of  IS  and  DA  are  opposed: 

IS  wants  to  develop  systems  as  quickly  as  possible. 

DA  wants  to  guarantee  data  quality  and  is  not  interested  in 
"putting  out  fires." 


DA  needs  to  satisfy  theend  users,  and  therefore  DA  should  be  in  some 
position^JfcSfi  md^es'^tsible  to  tt^emr^^  ' 

>f^should  be  in  a  high  enough  position  to  have  some  regulatory  and 
planning  authority. 

Although  DBA  ij  historiLuHy  uldei  than  DA,  DA  should  not  report  to. 
DBA. 

should  be  in  a  position  to  interact  with  the  company's  planning  and 

w- 

control  organization. 
Three  possible  positions  for  DA  are  analyzed  below. 
REPORTING  TO  TOP  MANAGEMENT 
DA  is  a  staff  function  within  the  corporate  office. 

This  is  the  preferred  positior)j\"T> offers  the  maximum  leverage  for  achieving 
^h^orporate  data/information  resource  management  objectives. 

The  corporate  perspective  gives  a  better  view  of  the  information 
requirements  of  the  entire  organization. 
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Because  of  the  high  level  of  this  position,  DA  is  likely  to  receive  more 
cooperation  and  acceptance. 

o      3^ThG  ultimate  need  for  a  chief  information  officer  (CIO)  report4«§«to  the  chief 
executive  officer ^.jtvus  seen  by  itome  respondents^ 

One  person,  predicting  ClOs  in  the  future,  quoted  James  Martin: 
"information  is  the  competitive  edge  of  man's  future,  just  as  the  wheel 
was  the  competitive  edge  of  his  history." 


4^ a  major  utility  company  with  a  progressive  DA  functiohAa  position 


papei 


rldeclare?" 


jy  the  end  of  the  decade,  information  will  play  such  an 
important  role  in  the  company  that  it  should  begin  to  appear  as 
an  asset  on  Qlorporate  financial  reports. 

"As      role  of  information  increases,  consideration  should  be 

given  to  the  creation  of  a  Chief  Corporate  Information  Officer  . 
II 

o        If  these  predictions  are  valid,  there  will  be  a  trend  toward"©*^  reportfng  to  top 
management. 

2.       REPORTING  TO  THE  CONTROLLER 

o        This  arrangement  breaks  DA  away  from  the  IS  department.  However,  DA  is 
not  a  department  or  staff  function  in  its  own  right. 

This  arrangement,  like  the  above,  has  the  advantage  of  providing  a 
corporate  perspective  on  the  information  resources. 
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DA  gains  some  "muscle"  by  its  association  with  the  financial  authority 
of  the  controller's  office. 


REPORTING  TO  l,S. 


A^ 


This  arrangement  implies  two  opinions  of  DA. 

First,  it  is  a  way  of  reorienting  IS  toward  greater  user  satisfaction. 

e 

Second,  it  Is  a  responsibility  center  for  jnsuring  quality  in  system 
development  efforts. 

This  arrangement  creates  a  narrow  perspective  on  data  resource  management. 

It  creates  the  danger  that  users  will  be  alienated  by  the  misdirected 
control  imposed  through  the  data  dictionary. 

It  offers  little  opportunity  to  move  toward  directly  satisfying  some  of 
the  information  needs  of  higher  management. 

This  is  the  least  desirable  position. 


This  chapter  has  told  how  to  attain  certain  goals  through  certain  activities. 

The  goals  are  the  benefits  resulting  from  a  CDM  and  integrated, 
expansible  databases: 


SUMMARY 
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End-user  computing  that  is  both  easier  for  the  user  and  better 
controlled. 


More  productive  professional  programming. 
The  basis  for  an  executive  information  system. 
The  activities  are  both  human  and  technical.  They  include: 
Getting  top  management  support. 

Generating  a  business  model  that  will  in  turn  lead  to  a  CDM  for 
the  enterprise. 

Normalizing  the  CDM  to  lay  the  groundwork  for  integrated, 


Using  a  DD  and  DBMS,  partly  to  minimize  conversion  problems. 


Developing  views  of  these  datqbases  that  will  best  serve  the 


If  not  all  the  above  activities  are  possible,  some  compromise 
approaches  to  good  DA  can  be  taken. 

Finally,  good  DA  deserves  a  high  position  in  the  hierarchy  of  the 
enterprise.  At  a  minimum,  it  should  report  to  some  kind  of  planning 
and  control  organization. 


databases. 


Actually  developing  the  physical  databases. 


users. 
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MAINTENANCE  AND  HUAAAN  ISSUES 


A.      CHANGING  THE  CULTURE 


o        Responcjents  frequently  talked  about  DA's  need  to  "change  the  culture"  in 
which  t^iLt  worked,^ But  what  is  a  culture? 

IS  ^ 

A  culture  is  a  set  of  roles. 

In  a  primitive  culture,  roles  include  animal  skinners  and 
cleaners,  witch  doctors,  and  chieftains. 

In  an  IS  culture,  roles  include  data  entry  clerks,  business  and 
scientific  programmers,  and  IS  managers. 

A  culture  is  a  set  of  values. 

In  a  pimitive  culture,  magical  ability  is  valued. 

In  an  IS  culture,  programming  ability  is  valued. 

People  in  a  culture  are  threatened  by  anything  that  will  change  their 
roles  and  values.  Technology  makes  such  changes. 

Modern  medicine  can  outshme-4he  witch  doctors'  magic^  and 
downgrad^  their  role. 
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Database  technology  threatens  to  change  roles  and  values  in  the 


IS  culture.  (^afC^'^^ 

The  professional  histories  of  three  pd^folive  peuple  in  an  IS  culture  are 
outlined  in  Exhibit  Vil-I^lf  DA  infuses  modern  database  technology  into  their 
culture,  their  roles  and  values  w/ill  change. 


Business  programmer 

May  feel  that  their  expertise  in  structured  COBOL  is  being 
rendered  obsolete  ossothers  perform  well  with  FGLs. 

,         May  feel  insulted  that  people  are  now  talking  about  Customer 
Datci^^ases  rather  than  Accounts  Receivable. 

Scientifc  programmers;  \ 

May  look  down  on  those  who  do  not  understand  the  exciting 
package  concepts  in  Ada.  and  whe^^  instead  fuss  over  dull 
datcpases.  ^  ^ 

May  prefer  the  elegance  of  C  to  the  "hairiness"  of  large 
datccases. 

The  system  development  managers.*  \ 

May  suspect  that  their  system  development  expertise  is  not 
appreciated. 

May  wonder  whom  they  can  manage  if  ob'AolesecncG  oomcs  uporr"^ 
the  people  they.know  how  to  manage.tef         ^  irtfpU<ffl(l/<tv;;^ 
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The  concerns  of  these  people  beve-^me  element  of  truth  behiiirj  I 
will  not  allay  their  concerns  by  denying  this  fact. 


DA 


TH!»^  better  approach  is  to  point  out  hiatorioal  faok  New  technology  always 
creates  new  opportunties  as  well  as  displacements. 

Business  progrannmers  can  apply  their  knowledge  of  Accounts 
Receivable  to  the  design  of  user  views  of  the  CDM,  and  these  views 
will  make  the  programmer  and  others  more  productive  in  the  future. 

Scientific  programmers  may  find  the  mathematics  of  normalization  as 
interesting  as  those  of  transform  theory— and,  in  some  businesses,  more 
valuable. 

IS  managers  may  be  able  to  apply  their  system  development  and 
managerial  talents  to  helping  a  larger  group  of  predictably  naive  end 
users. 

A  time  of  change  is  always  a  time  of  testing.  If  the  DA  concept  is  seriously 
implemented,  then  there  will  be  real  changes  and  tests.  In  general,  the 
change  will  affect: 

End  users. 

Other  technicians  as  well  as  the  programmers. 

Other  managers  as  well  as  the  head  of  system  development. 

If  DA  has  the  charter  or  willingness  to  do  so,  it  should  deal  with  these  changes 
at  two  levels: 

Politically,  at  the  managerial  level. 


-3-  (U-CDA-VII)  tpw  -  8/9m 


i: 


Through  training  at  the  lower  levels. 


The  word  "political"  is  used  in  its  good  sense:  Working  out  agreements  for  the 
good  of  the  community. 

Conscientious  establishment  of  the  DA  concept  will  probably  require 
changes  in  the  organizational  structure.  A  good  political  tactic  is  for 
the  DA  manager  to  confer  with  his  or  her  director  and  jointly  work  out 
a  tentative  new  organization  chart.  Then,  in  deciding  to  what  extent 
to  implement  that  chart,  let  the  DA  leader  take  the  technical  and 
consulting  role  while  the  director  takes  the  executive  and  political 
role. 

Training  has  two  advantages. 

For  those  who  are  trained,  it  promises  to  solve  their  problems— 
to  give  them  new  or  expanded  skills. 

It  is  not  emotional.  In  most  progressive  companies,  occasional 
training  sessions  are  expected,  and  a  training  department  is  set 
up  to  facilitate  those  sessions. 


ase 


Here  is  a  tip  for  the  training  departmen^J^^  Training  in  dot 
technology  is  based  on  specific  technical  facts.  It  is  not  like  leadership 
training;  it  is  not  based  on  psychology. 

-    ^^^^n  effective  and  well-established  methodology      available  to  teach 

technical  skills.  +4-4^|jTstructional  System  Development,  or  ^SD^It  is-e-2- 
well  known  and  is  documented,  among  other  places,  in  Air  Force 
Manuals  50-2  and  50-8.  ^^'f 

sLol^it  approached  by  training  consultants  who  ^n't  speM^  ISD^ 
ymJl^^  '^doRU  hire  them. 
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Finally,  going  back  to  Chapter  VI,  there  is  tremendous  value  in  firm,  open 
support  from  t+i^upper  management. 


AAAINTENANCE 


Stability  is  perhaps  the  greatest  single  appeal  of  the  data  model.  Data  types 
(e.g.,  defect  rates,  orders,  hours  of  work)  tend  to  be  more  stable  than  the 
mechanisms  or  processes  that  create  th«^se  data. 

If  a  data  model  is  properly  built  (i.e.,  adequately  normalized),  it  should  change 
v^ry  little  -  u^unti|^e  company  gets  a  new  type  of  business,  or  until  the 
structure  of  the  enterprise  changes  significantly. 

Still,  the  data  model  is  a  snapshot  (albeit  an  expensive  snapshot)  of  the 
enterprise,  and  the  enterprise  does  change.  All  data  model  managers  surveyed 
by  INPUT  reported  at  least  some  maintenance  activity.  with  that 

activity  comes  problems. 

The  biggest  problem  is  ^ human  preblam^  People  tend  to  neglect 
maintenance. 


Documentation    is    part    of    the    infrastructure,    and    it  is 

unqlamorous  and  seems  never  urgent.   So,  under  pressure,  the 

9-  in  H\r«r 

infrastructure  deteriorates:   People  neglect  PpiC  maintenance 

"put** out  fires."    (The  analogy  is  apt:    Does  the  crew  of  a  fire 

truck  stop  and  patch  po^Tiploo  on  the  way  to  a  blazing  house?) 

Perhaps  because  of  the  lack  of  glamour,  few  people  seem  ^ 
interested  in  doing  tl'^maintenance  work. 
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A  related  problem  is  technical.  A  data  model  is  complicated. 

h 

fhs    doctoral    respondent,    who    is    interested   in  artificial 
intelligence,    commented   that    both   *i^^ata    model^  and  ^ 
"knowledge baseA  system'J    (in    artificial    intelligence)  are 
"fragile."    That  is,  both  require  a  skillful  maintainer.    A  few 
mistakes  (e.g.,  with  key  attribute  classes)  can  do  gret  damage  to 

r 

the  structure  that  enables  the  data  to  convey  useful  information 
to  people. 


The  most  creative  people,  however,  prefer  design  work  to 
maintenance  work. 

If  maintenance  of  an  application  program  is  ♦ot^eglected,  people  are  afraid 
to  use  the  program  and  don't  trust  its  documentation.  The  same  fate  can  be- 
fall data  modeR 

A 


DA  managers  have  a  choice. 

They  can  budget  perhaps  half  a  person  pkts-  a  software  tool  for 
maintenance. 

Or  they  can  neglect  maintenance  and  risk  losing  the  base  of  hi^  system. 
C.      TOOLS  AND  CONSULTANTS 


Data  will  be 


o        A  "new  pressure"  regarding  DA  was  explained  in  Chapter 

shared,  because  it  l^work  to  generate  and  input  data.  DA  can  either  fight  the 
data-sharing  trend,  or  facilitate  and  co-opt  it.  QfTpStitir^j  thfl  word  "rnaftp^,  .^zZ__}^ 

^-oT^/mcqna  "join  q  movement  and  then  take  it  over;-^  ~ 
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DA  can  co-opt  the  data-sharing  movement  if  it  can  offer  superior  wares  that 
users  will  use.  The  need  is  to  satisfy  the  users. 


People  like  to  play  with  tools. 

FGLs  are  useful  tools.  DA  should  encourage  their  use. 

Because  some  FGLs  are  linked  to  specific  DBMS  packages,  the 
FGL^should  be  a  consideration  in  the  selection  of  a  DBMS. 

People  don't  like  to  follow  standards. 

So,  where  possible,  the  DD  should  automate  standards  so  that 
the  user  never  sees  the  standards. 

Where  standards  must  be  written  for  the  use^^..4hey  should  be 
^2_ete€if»     Sources  of  clarity  are  cited  under  Human  Factors 
Engineering,  below. 

Consultants  were  mentioned  previously  in  connection  with  purely  technical 
roles:  providing  expertise  (e.g.,  or^^^m^deling  or  normalization)  that  the 
company  not  have.  However^ H?Te^ can  also  be  valuable  because  they  are 
unbiased  with  respect  to  the  company. 

Consultants  have  their  own  biases,  which  are  very  strong. 

They  want  to  promote  their  own  ideas. 

They  want  to  sell  their  own  services. 

But  they  typically  have  no  biases  regarding  political  issues  in  the 
company. 
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Therefore  consultants  are  often  very  effective  in  explaining  a  new  project. 
People  will  listen  to  them. 


The  older  consultants  can  recount  histories  of  similar  project>at  other 

A 

companies. 


recommends  the  limited  use  of  s«ct^consultants  as  a  way  of  clarifying 
the  interaction  between  the  technical  and  the  human  aspects  of  DA^^ 

^     •^{^-^riu\u\iu\  In  ilii.  .  I  iiniltnqtg  '^<>ntioned  earlier,  a  candidate  consultant 

irvthjr.  finlH  if  Mr     lim  VnnHprhnof ,  of  ^nn   Ingn  rnpiyf  ^""j     'llifnmin,  ^ 


D.      HUMAN  FACTORS  ENGINEERING 

7 


A  "^^is 


o  /\TtYM^is  an  established  discipline.  Much  of  "1"  involves  the  physical  design  of 
workspaces,  control  devices,  etc.,  and  is  not  relevant  to  DA.  But  parts  of 
HFE  are  relevant,  and  they  should  be  used.  These  include: 

Designing  the  "display"  to  be  visible  to  the  eye  and  understandable  to 
the  mind.  This  part  of  HFE  sometimes  has  relevance  to  DA.  Some  of 
its  principles  and  findings  concern: 

,         Error  rates  in  scanning  digits. 

Parts  of  video  displays  that  are  most  likely  to  be  seen. 

Changes  that  are  most  and  least  likely  to  be  noticed. 
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The  understandability  of  labels  and  messages. 


When  "information  overload"  occurs. 
0 

Making  the  procedure  compatible  with  human  nature.  This  concerns 
the  effects  of  sequencing  human  actions  in  different  ways.  For 
example: 

If  a  person  hears  a  number  and  says  it  to  someone  else,  thoy-gr^ 
less  likely  to  make  a  mistake  and  also  less  likely  to  remember 
the  number. 

If  a  person  hears  a  number  and  writes  it  to  someone  else,  m&f 
i^QFe^more  likely  to  make  a  mistake  but  also  more  likely  to 
remember  the  number. 

If  DA  gets  involved  in  designing  any  kind  of  complex  formatj^that  must  be 
understood  by  a  variety  of  users,  HFE  could  probably  help  in  the  design 
process. 
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VIII 


^0  ft)V^iW^SfA^'^'^ 
RECOMAAENDATIONS  FOR  A  BA* STRATEGY 


A. 


PREMISES 


o 


DA,  buttressed  by  data-oriented  development,  constitutes  a  wave  of  the 
future. 


End-user  computing  is  proliferating.  This  causes  a  dilemma. 

.         Much  greater  responsiveness  to  user  needs  is  possible. 

Without  an  adequate  DA  function,  much  end-user  computing  will 
(a)  be  based  on  inaccurate  data,  /(b)  degrade  the  accuracy  and 
security  of  corporate  data,  or  (c)  both  use  and  create  bad  data. 


Increasing  the  speed  with  which  IS  produces  new  application 
systems. 


DA  offers  the  future  promise  of  contributing  to  better  executive 
information  systems. 


DA  offers  the  immediate  promise  of  significant! 


o 


DA  will  significantly  change  the  structure  of  IS  organizations. 
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The  scope  of  application  development  will  narrow  as  "consumer 
computing"  produces  small  systems.  IS  will  concentrate  more  on  large 
application  systems  and  operating  systems. 

As  DA  is  brought  in  to  IS  organizations,  DA  will  grow.  AtTCnTwill  be 
perceived  as  encroaching  on  IS  turf. 

B.       RECOMMENDED  STRATEGY 

o        Three  strategic  questions  must  be  answered. 

In  a  given  organization,  in  what  areas  should  DA  be  first  implemented? 

What  are  the  human  considerations  in  implementation? 

What  is  the  best  technical  approach? 

o        The  first  implementation  should  be  performed  in  an  organization  or  sub- 
organization  that  isV', 


Large  enough  to  allow  demonstration  of  benefits,  but  small  enough  to 
minimize  risks. 

Integrated,  in  the  sense  that  it  would  benefit  from  an  integrated 
database  system. 


o        Human  considerations  span-tho-organizational  pyramid. 
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Some  technicians  will  need  new  training  to  retain  their  value  to  the 
company. 

Satisfaction  of  end-users  will  be  a  major  goal  of  DA.  if  end-users  are 
not  satisfied  with  DA's  products,  they  will  either  not  use  or  misuse 
corporate  data. 

DA  will  change  the  organizational  structure.  A  frank  approach  to 
these  changes  will  minimize  covert  politicking. 

Without  real  top  management  support,  DA  is  likely  to  fail.  It  is 
recommended  that  DA  report  to  a  high-level  planning  and  control 
function,  or  that  it  be  on  the  corporate  staff. 

a 

The  technical  heart  of  implementation  is  the  three-schem^  architecture 
through  which  a  conceptual  data  model  can  be  generated. 

Prior  development  of  a  business  model  will  minimize  the  risk  of 
overlooking  vital  areas  of  business  information. 

It  is  essential  that  the  conceptual  data  model  be  normalized  if  the  later 
physical  datajhrises  are  to  provide  the  benefits  of  integration^ 
ujjdeF-P^emis^y^!^  A^, 

Enforcement  of  data  standards  is  necessary  if  the  databases  are  to  be 
maintained  and  retain  their  value.  An  active  dato^  dictionary  is 
recommended  to  automatically  enforce  standards. 
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CONCLUSIONS 


This  report  has  covered  the  technical  and  human  problems  in  establishing  a 
good  DA  function,  as  well  as  the  values  of  such  a  function. 

The  technical  problems  are  the  easiest.  Effective  technical  approaches 
are  known,  and  one  can  buy  the  talent  to  implement  th^se  approaches. 

The  human  problems  can  be  minimized  by: 

Explaining  clearly  to  top  management  what  is  being  done/and 
why. 

OA  ^  4 

Collaborating  in^planning^the  organizational  changes  that  any 
new  technology  will  entnil.  Q- 

Using  established  principles  of  training  and  human  factors 
engineering. 

There  are  positive  values  to  good  DA,  and  negative  values  to 
inadequate  DA. 

Without  adequate  DA,  the  organization  faces  increasing 
problems  with  data  that  are  redundant,  inaccurate,  and 
unavailable. 


With  good  DA,  the  evidence  points  to  better  application 
programming,  better  "consumer  computing,"  and  more  truly 
informative  management  information  systems. 
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DATA  ADMINISTRATION 
QUESTIONS  FOR  USERS 


I.  First,  let's  try  to  define  some  terms. 

1.  How  do  you  define  Data  Administration  (DA)? 

2.  What  are  the  most  Important  other  concepts  (e.g.. 
Information  Resource  Management,  Database  Administration) 
from  which  DA  should  be  distinguished? 

3.  How  do  you  define  data  modeling  or  information  modeling? 

4.  Which  of  the  above  are  you  most  Interested  in? 

5.  Why? 

II.  Now...  some  questions  about  data  modeling. 

1.  What  tools  support  It? 

2.  How  well? 

3.  What  techniques...? 
.4.    How  well? 

5.  What  tools  and  techniques  are  missing? 

6.  Have  you  been  Involved  in  data  modeling,  or  are  you 
familiar  with  cases  of  it? 

7.  In  each  case,  what  was  the  scope  of  the  effort,  and 
the  costs? 

8.  In  general,  where  do  you  think  data  modeling  should  and 
should  not  be  employed? 

9.  Can  you  name  any  good  consultants  in  data  modeling? 

10.     After  someone  builds  a  big  data  model,  it  is  perishable: 

What  Information  do  you  have  on  the  costs  of  maintaining  it? 

III.  Returning  to  DA  in  general,  what  do  you  think  are  the  most 
promising 

1.  tools? 

2.  methodologies? 

3.  consultants? 

4.  Can  you  specify  any  needs  for  integration  of  tools,  to 
make  them  work  better  as  a  set,  or  of  tools  and  methods? 

IV.  Now...  some  practical  questions  about  DA. 

1.  How  is  your  DA  function  organized?  How  big  is  it? 
2..  What  services  does  it  offer  to  your  DP  community? 

3.  What  restrictions  does  it  lay  on  them? 

4.  To  what  extent  is  DA  in  your  corporation  centralized? 

5.  What  kinds  of  environments  or  enterprises  need  highly 
centralized  DA  functions? 

6.  Why? 

V.  "Data  oriented  development"  is  widely  advocated  these  days. 

1.  Do  you  favor  it  over  "procedure  oriented  development"? 

2.  Why? 

3.  What  tools  and  techniques  support  it? 


VI.  Now  we'll  discuss  some  trends  or  factors  affecting  DA. 

1.  What  trends  concern  or  interest  you  most? 

2.  How  are  you  dealing  with  your  concerns? 

3.  In  what  Industries  and  environments  are  your  concerns 
most  and  least  shared? 

l».     (If  not  already  mentioned...)    Is  the  influx  of  personal 
computers  a  concern  to  DA? 

5.  How,  and  to  what  extent,  should  they  come  under  the 
influence  of  DA? 

6.  Do  you  have  a  concern  about  the  use  of  external 
commercial  databases? 

7.  What  should  DA's  role  be  regarding  that  usage? 

VII.  Now...  some  "bottom  line"  questions. 

1.  To  what  extent  is  good  DA  a  technical  vs.  a  management 
i  s  sue  ? 

2.  Can  you  give  us  any  example  of  bad  DA  caused  by  inadequate 
support  of  the  DA  function? 

3.  What  were  the  results? 

4.  Can  you  give  us  examples  of  bad  DA  caused  by  poor  strategy 
or  poor  practices? 

5.  What  were  the  results? 

6.  What  are  some  examples  of  good  DA? 

7.  What...  results? 

8.  Looking  at  the  basic  business  or  service  of  your  corpora- 
tion, how  would  you  say  that  DA  ultimately  affects  its 
productivity? 

VIII.  If  someone  gave  you  a  few  million  dollars  and  ordered  you  to 
retire,  what  advice  regarding  DA  would  you  give  to  your 
replacement  on  your  Job? 


17.      What  else  should  we  have  asked  you,  that  we  didn't? 


I   ^  DATA  ADMINISTRATION 

I   !  QUESTIONS  FOR  VENDORS 

li.' There's  a  cloud  of  terms  related  to  Data  Administration  (DA): 
IRM,  Information  Management,  Database  Administration,  Information 
Engineering,  etc.    What  term  do  you  favor  for  the  state-of-the-art 
data  administration  function,  and  why? 

2.  Do  you  supply  tools  or  methodology  consultants  for  data  modeling 
or  information  modeling?    If  so,  please  tell  us  about  them. 

3.  What,  as  a  rule  of  thumb,  is  the  cost  of  a  data  modeling  effort? 

4.  For  what  kinds  of  clients  is  it  most  and  least  valuable,  and 
why? 

5.  Can  you  give  any  case  histories  of  pay-offs  to  your  clients? 

6.  Who  are  your  major  competitors? 

7.  What  do  you  estimate  the  cost  to  be  of  maintaining  a  data  model 
after  it  is  built? 

8.  In  DA  in  general,  what  are  the  most  valuable  tools  available? 

9.  Methodologies...? 

10.  Do  you  see  any  need  for  integrated  sets  of  tools? 

11.  Consider  three  or  four  different  kinds  of  clients  of  yours. 
Can  you  tell  us  about  the  organization  and  responsibility  of  DA 

in  each  of  them?    If  the  organization,  etc;  are  not  ideal,  tell  us 
how  they  ought  to  be  changed. 

12.  Do  you  supply  tools  and  consultants  to  support  data  oriented 
development?    If  so,  tell  us  about  them  briefly.     If  so,  what  data 
can  you  give  us  on  the  benefits  your  clients  obtain  from  them? 

13.  Again  thinking  of  three  or  four  different  kinds  (sizes  and 
industries)  of  clients,  please  tell  us  what  trends  or  factors  are 
most  affecting  their  DA  function. 

14.  If  you  did  not  discuss  it  above,  tell  us  what  the  effects  on  DA 
are  and  should  be  of  the  following:     (a)  the  influx  of  personal 
computers^  (b)  access  to  external,  commercial  database  services. 

15.  Being  as  quantitative  as  possible,  what  case  histories  can  you 
give  of  good  DB  functions  helping  organizations,  and  inadequate  ones 
making  them  less  competitive? 

16.  If  you  were  talking  to  the  CEO  of  a  prospective  client,  what  would 
you  tell  him  about  the  way  DA  ultimately  affects  his  productivity? 

17.  If  a  friend  of  yours  had  Just  been  made  responsible  for  DA  in 
a  large  company,  what  advice  would  you  give  him? 

18.  What  else  should  we  have  asked  you,  that  we  didn't? 
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CONSULTING  SERVICES  AGREEMENT 
EXHIBIT  A 


CONSULTANT: 

REPORT  TO: 
START  DATE: 
PROJECT : 
PROJECT  CODE: 


R.  K.  Overton,  PhD. 
P.O.  Box  2037 

Capistrano  Beach,  California  92624 

I.  Steven  Kerns,  Program  Manager 

March  19,  1984        COMPLETION  DATE:     May  4,  1984 

Data  Administration  Experiences  and  Outlook 

UCDA 


TASK  DESCRIPTION 


Consultant  will  act  as  author  for  a  study  and  report  for  the  1984 
Information  Systems  Program  on  the  subject  of  Data  Administration 
Experiences . 

The  consultant  will  perform  the  following  tasks  in  accordance  with  the 
project  schedule  (Exhibit  D). 

-  Poll  six  (6)  companies  via  telephone  (at  least  three  of  which  are 
INPUT  clients)  concerning  their  research  interest  for  this  pro- 
ject and  document  the  results; 

-  Develop  report  specifications  including: 

.        research  issues 
report  outline 

-  Conduct  at  least  25  interviews  with  users  and  vendors; 

-  Participate  in  the  midpoint  review  meeting; 

-  Do  analysis  and  writing  of  report  in  accordance  with  INPUT  stan- 
dards.    The  report  should  be  at  least  50  pages  in  lentgh,  plus 
appendices. 

Text 

Exhibits 

Table  of  contents 
List  of  exhibits 
Abstract  (50-100  words) 
Thank  You  Package 

-  Cover  letter 

-  Respondent  Summary 
Press  Release 


INPUT 


o        INPUT  will  provide  production  as  required,  typing,  graphics,  and 
quality  assurance. 


o        Progress  against  schedule  is  to  be  reported  to  Steven  Kerns  each 

Friday  morning.  Weekly  time  sheets  and  expenses  are  to  be  submitted 
to  accounting  on  Friday  mornings  (Exhibits  li  &  C). 

DELIVERABLES/PAYMENT  SCHEDULE 

o        Consultant  will  submit  report  in  typed  form  with  legible  exhibits 
attached. 

o        Approval  of  the  report  will  be  based  on  standards  used  by  INPUT 
in  the  publication  of  similar  studies. 

o        Upon  completion  of  approved  final  report,  $4,675  will  be  paid  to 
consultant.    Consultant  will  receive  a  bonus  of  $425  if  the  first 
draft  of  all  deliverables  are  received  by  INPUT  by  April  27,  1984 
and  all  revisions  to  these  drafts  are  delivered  to  INPUT  by  consul- 
tant within  three  working  days  from  INPUT' s  request  and  such  revis- 
ions are  acceptable  to  INPUT.     The  bonus  is  immediately  due  upon 
satisfactory  completion  of  the  above  conditions. 


AUTHORIZED  BY  INPUT:  ACCEPTED  BY: 


James  G.  Grugan,  Vice  President  R.  K.  Overton 


Date  Date 
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COMPLETION  DATE:     May  4,  1984 


PROJECT : 


Data  Administration  Experiences  and  Outlook 


PROJECT  CODE: 
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TASK  DESCRIPTION 


o  Consultant  will  act  as  author  for  a  study  and  report  for  the  1984 
Information  Systems  Program  on  the  subject  of  Data  Administration 
Experiences. 

o      The  consultant  will  perform  the  following  tasks  in  accordance  with  the 
project  schedule  (Exhibit  D). 


Poll  six  (6)  companies  via  telephone  (at  least  three  of  which  are 
INPUT  clients)  concerning  their  research  interest  for  this  pro- 
ject and  document  the  results; 
Develop  report  specitications  including: 


Conduct  at  least  25  interviews  with  users  and  vendors; 
Participate  in  the  midpoint  review  meeting; 

Do  analysis  and  writing  of  report  in  accordance  with  INPUT  stan- 
dards.    The  report  should  be  at  least  50  pages  in  lentgh,  plus 
appendices . 
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Table  of  contents 
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-  Cover  letter 
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Press  Release 
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o        INPUT  will  provide  production  as  required,  typing,  graphics,  and 
quality  assurance. 


o        Progress  against  schedule  is  to  be  reported  to  Steven  Kerns  each 

Friday  morning.  Weekly  time  sheets  and  expenses  are  to  be  submitted 
to  accounting  on  Friday  mornings  (Exhibits  b  &  C). 

DELIVERABLES/PAYMENT  SCHEDULE 

o        Consultant  will  submit  report  in  typed  form  with  legible  exhibits 
attached. 

o        Approval  of  the  report  will  be  based  on  standards  used  by  INPUT 
in  the  publication  of  similar  studies. 

o        Upon  completion  of  approved  final  report,  $4,675  will  be  paid  to 
consultant.    Consultant  will  receive  a  bonus  of  $425  if  the  first 
draft  of  all  deliverables  are  received  by  INPUT  by  April  27,  1984 
and  all  revisions  to  these  drafts  are  delivered  to  INPUT  by  consul- 
tant within  three  working  days  from  INPUT' s  request  and  such  revis- 
ions are  acceptable  to  INPUT.     The  bonus  is  immediately  due  upon 
satisfactory  completion  of  the  above  conditions. 
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R.  K.  Overton,  Ph.D. 


Box  2037,  Capistrano  Beach 
California  92624  USA 
(714)  493-3677 


Technical  Business  Development  Specialist 

Friday  afternoon 
23  March  1984 


I «  Steven  Kerns 

INPUT  •  . 

19^3  Landings  Dr.  • ' " ' 
Mountain  View,  GA  940^3 

Dear  Steve j 

I've  talked  with  five  of  your  clients  and  three  of  my 
contacts,  and  the  results  have  influenced  the  first 
cut  at  the  Data  Administration  project  specification 
statement  (enclosed). 

The  contract  came  this  morning.    I'll  sign  and  return 
it.     I  have  some  trivial  questions  (about  expenses, 
reporting,  etc.),  but  they  can  wait  until  I  return 
from  Colorado. 

I  have  not  received  copies  of  the  cover  letter,  abstract, 
and  press  release  requirements. 

I  think  I've  worked  (but,  unfortunately,  not  billed) 
sixty  hours  a  week  for  the  last  couple  of  weeks.    Now  , 
I  look  forward  to  being  able  to  concentrate  almost 
exclusively  on  the  Data  Administration  report  after  I 
return  from  TRW/Colorado. 

The  project  was  interesting  from  the  outset;  and,  as  I  - 
talk  to  your  clients  and  my  friends,  it  becomes  even 
more  exciting.     Now  we'll  try  to  communicate  that 
excitement  to  INPUT'S  clients. 

Best  regards,         .        -:   '       ■  ■ 


Richard  K.  Overton 


hvs 
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PROJECT  SPECIFICATION  STATEMENT 


A.    Project  Code:     O  C  b  A-  b.    Program       X  S  P 
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D.    Objective:  f  X^tH    U^a^  -^x^qlJCCv^  a.al<!  - 


E.    Audience  (order  of  priority) 


User/ 
Vendor 

Job  Function 

Type 
Company 

Company 
Characteristics 

1 

2 

3 

U  ^ 

4 

5 

F.    Reasons  for  Choosing  the  Subject. 
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DATA  AmimsT^TiQ}^ :  i^m*t^  4CM^ 


I .  INTRODUCTION 


II.     EXECUTIVE  SUMMARY 


III.     PRESSURES  FOR  GOOD  DATA  ADMINISTRATION  ^ 

A.  What  is  good  data  administration?     (1%  pages) 

A  company's  data  represents  an  investment.     Data  . 
Administration  (DA)  is  a  rational  attempt  to  maximize  , 
the  return  on  this  investment.  ^Jh^V 

DA  is  "good  to  the  extent  that  it  succeeds  in  this  n>j^ 
attempt.     It  is  also  "good"  to  the  extent  that  it  ^ 
delivers  what  users  and  executives  expect. 

B.  Current  Trends  and  Publicity  (1  page) 

Users  of  DA  and  DP  services  are  changing.     Users  are 
becoming  more  sophisticated  and  less  clearly  defined.  Users 
are  more  transient,  and  their  uses  are  less  planned.  Personal 
computers  are  viewed  as  demand-driven  information  delivery 
engines.     Decision  support  systems,  distributed  data  processing, 
and  telecommunications  are  heavily  publicized.     But  basic 
problems  grow:     It  becomes  harder  to  guarantee  security  and 
currency  of  data. 

C.  Longer-term  Trends   (2  pages) 

Over  the  next  three  years  there  will  be  a  trend  toward 
data  being  delivered  to  users  in  three  stages. 

1.  DA  will  control  a  data  model  and  data  structure 
of  the  enterprise. 

2.  Users'   decision  support  systems  will  tap  into  this 
data  structure  and  analyze  the  relevant  data. 

3.  Users  will  view  the  results  of  the  analyses  in 
displays  that  have  something  of  the  character  of 
Lotus  spread  sheets. 

For  at  least  a  decade,  there  has  been  a  trend  away  from 


managers  managing  computers  per  se ,  and  toward  them  managing 
data. 

D.  The  Executive  View  (1  page) 
The  economic  world  is  becoming  more  competitive.  Japan 

is  famous  for  its  "pervasiveness  of  information  gathering 
(and) ...  search  for  focused  information."    Executives  will  put 
increased  pressures  on  their  Information  Systems  directors, 
asking  them  for  information  that  they  can  understand,  that  is 
based  on  accurate  and  complete  data. 

E.  The  Centralization  Issue  (2  pages) 
"Good"  data  administration  begins  to  sound  omniscient. 

It  raises  the  issue  of  whether  a  central  DA  function  could  and 
should  manage  all  data.     It  raises  the  practical  question  of 
the  value  of  investments  in  strong  and  good  DA. 

THE  THEORY  AND  RESULTS  OF  GOOD  DA 

A.  The  Infrastructure  Argument  (2^pages) 
A  strong  DA  system  is  an  infrastructure.     It  is  a  network 

of  highways  or  power  lines.     As  such,   it  cannot  be  justified 
by  any  single  application  that  is  made  of  it,  but  by  the 
collective  set  of  usages.     DA  consultants  claim  it  help  solves 
a  long  set  of  problems,  of  which  the  most  immediate  are  poor 
data  quality,   integrability ,  and  accessibility. 

B.  Logical  Applications  of  the  Infrastructure   (2  pages) 
Strong  logical  arguments  can  be  made  that  some  pay-offs 

would  result  from  the  infrastructure. 


1.  New  application  programs  would  be  easier  to  write, 
especially  with  the  aid  of  fourth-generation  languages. 

2.  Maintainability  of  existing  application  programs 
would  be  increased. 

3.  Data  would  carry  more  information  because  they  would 
be  less  dependent  on  non-standard  contexts. 

4.  Lower  costs  would  be  incurred  for  maintaining  and 
securing  redundant  data. 

5.  Auditability  should  be  enhanced. 

6.  Data  could  be  made  available  to  users  in  views 
tailored  to  them.     Therefore,  the  users  would  be 
more  productive. 

7.  Data  could  be  translated  into  tactical  and  strategic 
information,  so  that  "generals"  could  have  "higher- 
level  views"  of  the  decisions  facing  them. 

C.     Some  Actual  Results  (2  pages)  J^jt^ 

DA  is  new  enough,  and  the  pay-off  time  is  long  enough,  that 
"We're  just  now  on  the  brink  of  some  success  stories."  Actual, 
dociamented  results  are  not  common.     A  few  of  them  are  : 
1.     DA  and  fourth  generation  languages  are  rapidly 
^  generating  understandable  budget  reports. 

Y     2.     A  marketing  department's  flexibility  of  policy  was 
\^  improved. 

3.     A  nuclear  utility  responded  rapidly  to  the  Nuclear 
Regulatory  Commi^i^ion '  s  urgent  request  for  data. 


4.  A  manufacturing  company  identified  its  most  profitable 
markets . 

5.  In  a  company  without  DA,   a  vice  president  asked  for 
cost  figures  and  got  three  different  numbers  from 
three  different  sources. 

6.  (Others... to  come.) 

D.     Projects  in  Process   (1  page) 

Aerospace  manufacturers  are  trying  to  integrate  CAD  and 
CAM.     This  requires  a  strong  DA  function.     Pay-off  would  be 
huge.     GM  and  other  companies  are  making  similar  attempts. 
A  majority  of  the  surveyed  companies  were  takipg^^some  steps 
toward  data-oriented  development.  ^^^^ 
GUIDELINES:     WHO  REALLY  NEEDS  DA? 

A.  Deciding  Who  You  Are  (1  page) 
No  intelligent  investment  in  DA  can  be  made  until  one 

identifies  what  or  whom  DA  serves.     The  hallmark  of  DA  is 
^integration,  and  DA  should  serve  a  rather  self-contained  enter- 
ijj/prise.     The  first  step  is  to  identify  that  enterprise. 

B.  Volatility  (%  page) 
Enterprises  in  volatile  industries  tend  to  need  DA  more 

than  those  in  stable  fields.  ^ 

C.  Size  (%  page)  ^  ,  IAmJ^^  ^  ^ 
Larger  enterprises  tend  to  need*  DA  more  than  smaller  ones. 

D.  Interactivity  (%  page) 
Enterprises  with  many  internal  interactions  need  DA  more 

than  those  with  a  simpler  set  of  internal  functions. 


HOW  TO  SET  UP  OR  STRENGTHEN  DA    ^  jf!h^  /)  ."^  s.UwJ^ 


Cost  and  Support  (1  pag^  'yi/M^ 
Estimate  the  costs.     Start  with  the  ^ules  of  thxjmb  in  this 
paper.     Estimate  the  benefits.     Include  benefits  outside  the 


B.     Modeling  (2  pages)  yjV^ '-^ 

....    .    '     ,   ,      ,  ^ 


IS  department.     Get  top  management  support.  L***-^ 


Get  a  methodology,  and  develop  a'  busiiiess  model.  Relate 
the  business  model  to  the  data  used  in  the  business  functions. 
Remember  that  the  mechanisms  performing  those  functions  will 
change.     Build  a  data  architecture,  with  a  logical  view  of  the 
data.     Then  plan  for  an  information  system  architecture,  with 
a  computer  view  of  the  data.  4  qM"^ 

C.  DBMS  and  Data  Dictionary  (%  page) 
Get  a  good  DBMS  that  interacts  with  a  Data  Dictionary. 

D.  Tools  and  Construction  (1  page)  ^^r'^^^ 
Get  software  tools  which  help/you  normalize  or  cluster  the 

data  for  maximirai  modularity.   /Then  build  up  the  data  in  layers, 
using  a  valid  foundation  before  you  build  the  next  layer. 

E.  Alternatives  to  Modeling  (%  page) 

 "The  above  steps  may  represent  more  front-end  analysis  than 


some  enterprises  are  willing  to  buy.     The  modeling,  in  particular, 
may  seem  a  questionable  investment.     A  less  aggressive  approach 
is  to  start  with  the  establishment  of  data  standards  and  use 
them  to  move  toward  a  more  mature  DA  environment.  4^^=*^  . 
F.     Place  in  Enterprise  (1  page)  UU^r'^^^ f^^^l 

DA  should  be  separate  from  applications  system  development. 


It  should  interact  with  the  enterprises ' s  planning  and  control 
organization. 


VII.     MAINTENANCE  AND  HUMAN  ISSUES 


A.     Changing  the  Culture  (1%  pages) 

People  tend  to  think  in  terms  like  Accounts  Payable.  They 
do  not  tend  to  think  in  terms  like  Customer  Database.  The 
latter  terms  represent  a  culture  that  may  be  shocked  by  some 
DA  concepts.     Also,  DA  will  fail  if  users  do  not  really  use 
its  wares.     So  DA  needs  to  combine  technology  with  salesmanship 
Q    to  change  the  culture.    Also  DA  may  meet  resistance  because 
its  functions  may  change  other  people's  (notably  programmers') 
over-all  jobs. 

Maintenance  (1  page) 

A  data  model  is  a  snapshot,  but  the  enterprise  moves.  DA 
na^ds  to  have  adequate  talent  and  power  to  maintain  the  base 
of  its  system.  ^(U^tid^ 
^.     Tools  and  Consultants   (1  page) 

It  is  h;aman  nature  to  like  to  play/with 
System  developers  may  interact  more  comfortably  with  DA  through 
interface  tools  like  fourth  generation  languages.  Also, 
consultants  may  be  listened  to  because  they  have  no  political 
bias  within  the  enterprise. 
D.     Hirnian  Factors  Engineering  (2  pages) 

This  is  an  established  discipline.     It  seeks  to  make  the  "tool" 
compatible  with  the  human  hand,  or  the  display  legible  to  the 
eye,  or  the  procedure  compatible  with  hioman  nature.     Some  of  its 


principles  should  be  used. 


R.  K.  Overton,  Ph.D. 

Technical  Business  Development  Specialist 


Box  2037,  Capistrano  Beach 
California  92624  USA 
(714)  493-3677 


11  May  1984 


I .  Steven  Kerns 
19^3  Landings  Drive 
Mountain  View,  CA  940^^3 

Dear  Steve t 

Welcome  back  from  France! 

Let  me  ease  your  transition  back  to  work  by  giving  you 
some  simple  items  for  the  Data  Administration  report. 

1.  A  copy  of  the  press  release  that  I 
had  previously  sent  you. 

J 

2.  A  cover  letter  for  the  report, 

3.  A  list  of  the  respondents  who  should 
get  copies  of  the  Executive  Summary. 

I  don't  think  you  need  anything  else  from  me.    But  if 
you  do,  just  give  me  a  call. 

You  might  give  me  a  call  anyway  after  you  have  had  a 
chance  to  settle  back  into  a  routine.    I'd  like  to  talk 
with  you  about  an  idea  for  another  report,  and  about 
another  possibility. 

Best  regards, 

Richard  K,  Overton 
hvs 
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press  release 
HOW  TO  TAME  'PROMISCUOUS  DATABASES' 
EXPLAINED  IN  NEW  INPUT  REPORT 


If  a  person  hears  "That  motorcycle  gets  103  miles  per 
gallon,"  he  may  think  about  his  car's  mileage  and  compare 
figures.    People  naturally  make  such  comparisons.    But  computers 
do  not.    Computers  may  have  one  database  about  motorcycles,  and 
another  about  cars.     Blending  such  databases  is  a  complex 
science. 

It  is  also  valuable.    People  can  use  computers  more 
effectively  if  they  know  what  information  lies  within  them, 

INPUT,  the  computer-oriented  market  research  and  consult- 
ing firm,  has  just  published  a  report  on  the  subject  that 
includes  that  science.    The  subject  is  Data  Administration. 

INPUT  di sects  the  trends  bringing  Data  Administration  into 
the  news.  Personal  computers  are  promiscuously  creating  data- 
bases "all  over  the  company,"  according  to  managers  interviewed 
for  the  report.    These  databases  need  to  be  "tamed." 

Executives  can  use  the  report  to  guide  them  in  bringing 
their  companies'  data  under  control.    The  report  features  a 
clear,  step-by-step  description  of  how  to  establish  or  strength- 
en Data  Administration. 

Data  Administration  is  an  art  as  well  as  a  science. 
Its  human  aspects  are  also  covered  in  the  report.    It  explains 


press  release  I 


that  new  opportunities  have  to  be  explained  to  employees, 
and  that  organizational  changes  have  to  be  made  as  the 
technical  advances  are  realized. 

Author  of  the  report  is  Dr.  Richard  K.  Overton,  who 
has  25  years  of  experience  in  advanced  computer  applications. 

The  report,  entitled  Data  Administration  Experiences 
and  Outlook,  is  part  of  INPUT'S  Information  Systems  Program 
on  Corporate  Systems  Planning.    It  is  available  for  $ 
from  INPUT,  I943  Landings  Dr.,  Mountain  View,  CA  940^3 
(415)  960-3990. 


COVER  LETTER 


date 


Dear  Client: 

The  enclosed  report,  Data  Administration  Experiences  and 
Outlook,  is  one  of  the  deliverables  in  your  subscription 
to  INPUT'S  Corporate  Systems  Planning  Program  in  Infor- 
mation Systems. 

We  "believe  this  report  will  be  interesting  as  well  as 
valuable  to  you.    It  offers  answers  to  critical  questions 
such  as 

What  does  Data  Administration  really  mean? 
Why  is  there  now  a  surge  of  interest  in  it? 

What  theoretical  advantages  does  it  offer? 
What  actual  experiences  have  come  from  it? 

What  human  issues  does  Data  Administration 
raise?    What  is  the  best  way  to  approach 
them? 

What  are  the  values  of  business  modeling 
and  database  normalization?    And  what  are 
the  costs? 

Where  is  a  strong  Data  Administration 
activity  most  valuable?    How  can  it  be 
established? 

As  with  all  of  our  reports,  we  look  forward  to  responding 
to  any  questions  about  related  issues  that  this  report  ma^ 
provoke. 


Sincerely, 


PEOPLE  TO  GET  COPIES 


OF  SUMMARY  DATA  ADMINISTRATION  REPORT 


Kenneth  S.  Teel 
School  of  Management 
Gal.  State  University 
6511  Driscoll  St. 
Long  Beach,  CA  908I5 

Peter  Freeman 
School  of  I.C.S. 
Univeraty  of  California 
Irvine,  CA  9271? 

Timothy  L.  Ramey 
6019  N,  Agnes 
Temple  City 
CA  9178O 

Mack  Alford 
University  of  Alabama 
213  Wynn  Dr. 
Huntsville,  AL  35805 

Richard  West 
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fNTRODUGTION 
Ob.iectivo.  Audienco.  and  Noed 

Data  Administration  is  boconing  moro  sophisticated,  and 
publicity  and  claims  about  it  are  growing.     So  is  confusion. 
The  objective  of  this  report  is  tos 

Clarify  what  Data  Administration  is  and  is  not. 

Delineate  the  pressures  affecting  it. 

Define  related  concepts,  such  as  data  and  information. 

Provide  clear  guidelines  for: 

Deciding  what  specific  enterprises    would  benefit 
from    Data  Administration.  ,  / 

•       Technically  establishing  or  strengthening''^^. 

Coping  with  the  human  aspects  of  Data  Administration. 

Primary  audience  i sJ±S/ manage rs^a  better  understanding  of 
Data  Administration  and  a  guidebook  to  its  management. 

Secondary  audience  is  Data  Administrators  and  Data- 
base Administrators  who  need  to  mesh  their  operations 
with  broader  organizational  eroals. 
'  _    Terciary  audience  is  vendors  of  Data  Administration 

tools  and  consultin.q:,  who  need  a  broanor  understanding 
of  their  markets. 


G.    m  Data  and  Iteto^tion-^  jji<^'^ '^XI 7^ 

+      The  report  precisely  defines  i       J  wteip' 


^5 

ormati  on 


+      "Uncertainty"  can  bo  defined  m 

is  that  which  reduces  uncertainty. 

One  bit  of  information  reduces  uncertainty  by  one  half. 


If  you  are  told  which  half  of  a  football  field  Q^t^s^ 
the  ball  is  on,  your  uncertainty  is  reduced  by  •"ap-^/'" 


one  half. 

If  a  computer  print- out  tells  ^j,^  which  of  two 
machines  is  CcVo •.'v"<\'^-   more  rfofects,  your  un- 
certainty is  reciucod  by  one  half.     The  print- 
out gives  you  one  bit  of  information. 

The  key  to  information  is  the  matrix  in  which  it  fits. 

•  Without  the  concei^t  of  the  football  field,  the 
location  of  the  ball  would  carry  no  information. 

•  V/ithout  the  matrix  of  comparison  of     the  two  machines, 
the  data  on  the  computer  print-out  would  convoy 

no  information. 
A  major  challenge  to  DA  is  to  see  that  data  loose'no 
information  as  they  are  transferred  from  one  matrix 
to  another...   or  to  re-structure  the  d^ta  to  provide 
information  to  the  new  m.atrix. 


I.  \  ^ 


V 


EXHIEIT  II  -  ^ 
0«  Dy\TA  AND  IN^ 


On  a  coPTDutor  Drint-out 
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'^■^ -^Bits*  Infrastructure 

A  serious  practical  problem  in  justifying  DA  is  that  its 

existence  really  demands  an  infrastructure. 

An  integrated  database,  like  that  illustrated  at  the 

bottom  of  Exhibit  II-2,  is  an  infrastructure.     It  is 
automated 

A&alogous  to/telephone  switching  equipment  or  to  a 
network  of  power  lines. 

Any  infrastructure  requires  a  capital  investment. 
This  investment  sseta  can  h  rarely  be  justified  by  any 
single  application, 

•  An  automated  switching  system  for  any  single^^ telephone 

customer  would  not  m.ake  economic  sense, 
A  large 

•  Aaj/inte grated  database  for  any  single  application 
program  would  not  make  econbm.ic  sense. 

However,  many  applications  are  predicted--  some  logically, 

and  some  on  faith. 

Current  experience  inciicates; 

•  The  preciictions  of  faster  application  programming  and 
more  satisfied  end-users  are  valid, 

•  Some  improvements  in  management  information  are  rqprted , 
e,g. ,  a  manufacturing  company  defined  a  profitable  market. 

•  Major  manufacturing  firms  have  high  ambitions:     They  want 
to  integrate  information  to  improve  the  "  or.q:ajiici  ty" 

of  their  manuf ac turin;z. 


EXHIBIT  II  -  ^ 
•5?Jffi.'  .DA3A  INFRASTRUCTURE 

+  Concept 

-  Analogies  to  dial  phones 

-  Requires  investment 

-  No  single  justification 

-  Many  predicted 

+    Current  experience 

-  Faster  application  programs 

-  Satisfied  end-users 

-  Marketing  strategies 

-  Ambitions  in  manufacturing 
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+      The  technical  germ  of  DA  is  the  " three -schemfjj^  architecture." 
+      Data  needed  by  the  enterprise  can  "be  organized  into  a 
conceptual  map  called  the  Conceptual  Data  Model  (CDM). 

The  CDM  is  described  independently  of  any  deviSe  that 

will  hold  the  actual  data. 

The  CDM  is  also  described  independently  of  any 
particular  user's  view  of  the  r^ata. 
The  CDM  is  exposed  to  a  vital  technical  process 
called  "normalization." 

•  Normalization  is  *ji  to  the  CDI;!  what  the  alphabet 
is  to  a  dctionary, 

•  V/ithout  normalization,  a  GD:.I  would  lack  a  logical 
access  path. 

V/ithout  normalization,  it  would  ix**nca  lack  a  framework 
\mder  which  new  entries  could  be  classified. 
A  business  model  is  develonod  to  make  sure  the  CDM 
does  contain  a  framework  in  which  to  represent  all  of 
the  information  needed  by  the  enterprise. 


EXHIBIT  II   -  7J  V, 

Hew  TO  -SR■7"UP^^5^ : 
CbM<        TECHNICAL  f^l®jaiOfiK  t'C  £  V*  t'O  ^ 


pa^^^?— 4 — (tho  next  psgp  is  1^,  not  2) 

.     J'^^K^''^¥^fi^i&&m^^f^  ADiv'INI  STRATI  ON 
What  is  Good  LA? 
History  and  Definitions 

Data  Administration  (DA)  is  a  rPl»tivf>ly  new  and  inconsistently 
defined  concept. 

Database  r'1anpe;ement  Systems  (PEflSs)  appeared  in  the  late  1960s, 

Data  Dictionaries  (DDs)  eiTiers;ed  in  the  1970s. 

The  term  DA  was  not  e;enerally  used  until  the  1980s, 

•  Now  there  is  a  population  explosion  of  new-born  articles 
about  DA  and  related  ccrcepts, 

•  A  new  journal,  Database,  concentrates  bxkb^  exclusively  on 
database-related  reports.     Widely  circulated  magazines  such  as 
Da tama ti on  and  Inf osystems  are  trying  to  (1)   define  DA,  and 
(2)  tell  their  readers  where  DA  should  be  located  in  their 
organi  zati  ons. 


•  The  ma ga zi ne  ^ry^^"^^J^^,^^^o|^  ^^jZ!'.^    t^lj'''" * 
Three  different  scopes  of  responsibility  are  carved  out  by 
different  definitions  of  DA. 

In  the  narrowest  definition,  DA  is  merely  the  "care  and  feedinsr" 


wri  ters 


•  Thi s  de f initinn" i s  wrong,  according  to  most  sckx*kxs  and 
almost  all  of  the  people  surveyed  by  INPUT, 

•  This    !■!  iiimiiiiii  I  definition  is  really  for  Database  Administra- 
tion (DBA). 

In  the  most  frequent  definition,  DA  is  DBA  plus  broader 
business  functions! 

•  S  Keeping  higher  e3*»cutives  informed  of  the  challenges  and 
opportunities  in  data  management. 


for  ^^^^•or^At.•r*.  .  page  ^ 


\ 


-  The  b*.^*^  definition  includes  the  above  plus  a  proactive 
responsibility:     to  derive  information  that  will  influence 
corporate  goals,  and  even  help  create  new  ones.  INPUT 

.'""'ot  ifj"^!  J^over  definition  for  DA 

-  Exhibit  III-I.  illustrates  the^e'derflni tfoniT 


Few  organizations  have  a  DA  function  that  meets  the  60^^ 
definition. 

-    Only  about  a  quarter  of  the  mainframes  now  in  use  ame 
supportflWI^  DBMSs.    <  •  ■  ■  - 

In  V  '^'i  . 

&t  that  quarter,  most  have  a  rather  narrowly  defined  DA 
function,  Pr~±Bmin^.^i»m*wAj^^i4i,^ 


-  A  company's  data  represent^  an  investment.     It  is  as  real  as 
the  company's  investments  in  ?=MB»i«^x>  equipm.ent,  or  in  training 
for  people. 

-  DA  is  a  rational  attempt  to  maximize  the  return  on  the  investment 
in  data. 

-  DA  is    goodie  \o  the  extent  that  it  succeeds  in  this  attem.pt. 

^\ 

+"Good"  DA  can  also  be  defined  pragmatically. 

-  It  is  good  to  the  extent  that  it  delivers  what  its  DP  community 
users  expect.     Help  in  making  them  more  productive. 

-  DA  is  even  better*  if  it  also  serves  as  the  basis  for 
realistic,  top-level  overview  reports  to  executives. 


p.  kk  1^4^) 


•  Upper-middle  manss:cnent  XR(;Mi  wants  to  soe  hie:hor-level 
comparisons:  What  are  the  backlogs  on  our  four  product 
lines?    Is  any  product  f^ivinfl:  us  undue  problems  with  defects? 

•  Top  executives  want  information  to  justify  high-level 
decisions:     We  could  lest  get  an  automatic  handling  and 
kitting  system  for  kk  hybrids,  or  we  could  get  a  precision 
milling  system  for  inertisl  products;  which  would  xixxvi 
W,xitL  give  us  the  gifnter  return  on  investment?    If  Matsushita 
could  compete  with  us  on  hybrids,  how  would  their  quality 
compare  with  ours? 

The  org  chart  in  Exhibit  III-6  is  a  hierarchy.     Answers  to 
questions  from  different  levels  on  the  hierarchy  must  come  from 
a  hierarchy  of  data. 


-  BTtTlbi-t  ^^^-7  ■Showg''^'cTr"'a--  hi  erarc-hy, 

-  \Note  that  data  move  up.     Then  they  loose  their  identity  but\ 
Viot  their  influence. 

t    \  Raw  data  on  the  autot)onder  are  not  used  after  the  first 
^step  up,  but  their  influence  is  felt  in  the  quality  data 
it  the  next  level,  and  in  market  share  estimates  at  the 

t(^  level.   — - — ■ 

Such  a  data  hi erarcly  shows  why  top  executives  believe  all  data 
ultimately  belong  to  the  company.     All  data  affecting  any  company 
function  could  ultimately  influence  top  executive  decisions. 
DA's  responsibilities,  broadly  defined,  include  creating  the  basis 
for  such  a  hierarchy. 


(III  continued,  D  continued) 


2.     Toward  a  Data  Utility 


I-.'idrilf?  managers  have  a?i  i'ncreasin 
to^e'xer6j.se"  di f f erent \odels  qu 


-  American  manufacturing  ism  movinf:  toward  radically  shortened 
production  runs  and  an  increasing;  xvariety  of  products.  This 
trend  increases  the  need  for  DSSs  to  answer  "Vfet  if"  questions 
about  new  factory  configurations  and  equipment. 

-  Financial  managers  need  support  in  dealing  with  increased 
economic  volatility. 

+      "What  if"  simulations  do  not  directly  concern  DA.     But  the  data 
needed  for  those  simulations  As  are  a  major  DA  issue. 

+      INPUT  respondents  agreed  that  "There's  a  lot  of  stored  data 
out  there"  in  both  kkh  corporation  and  application  databases. 
There  was  also  agreement  on  the  basic  challenge: 

-  To  control  the  data  (with  both  DDs  and  policies)... 

-  ...  so  the  data  can  be  extracted...  so  anyone  can  use  them. 

+      A  trend  is  seen  toward  the  Information  Center  concept,  or 

toward  a  Data  Utility.    End  users  would  "plufe  in"  to  the  Data 
Utility  and  create  their  own  reports. 

-  An  active  consultant  (Bill  Durell,  of  Cypress,  CA)  echoed 
a  dissenting  opinion:     The  concept  is  good,  but  it  "doesn't 
work"  now.     Reason:     The  data  are  poor.     Thhy  are: 

•  Redundant. 

•  Hidden. 

date 

•  Out  of  rixtx  and  icmxxiciixKKSxx  inaccurate. 

-  Kow  does  one  improve  the  data?    By  strengthening  the  DA 
function  as  indicated  in  Chapter  VI, 


n  (3n 


(III.  K.  cont'd) 


2.    Levels  of  Description 
Some 

+      Axfjjftk  of  INPUT'S  respondents  mentioned  "executive  informatioii 
systems"  in  addition  to  the  HarKaLi/nEaRXKRKRHixxHf BXKatkBii  usual 
term,  management  information  system  (MIS).     They  recognized  that, 
compared  to  lower  and  middle  management,  top  executives  need 
information  that  is  different.     Their  information  should 
SxExstKKxSkBKisi  Sever  a  broader  scope. 

Be  expressed  in  the  terms  and  concepts  with  which  executives 
work. 

•  MIS  specialists,  often  in  middle  management,  may  not  know 
the  executive  terms  and  concepts, 

•  Software  is  rarely  available  to  translate  raw  data  into 

those  terms  and  concepts, 

-    Exhibit  III  -  6  is  a  deliberately  Iksr  truncated  organization 
can 

chart.     It/illustrates  the  concepts  zt  in  which  different 
levels  of  management  are  interested, 

•  The  Rx  org  chart  describes  a  plant  that  manufactures  ki  hybrid 
electronic  mi crocircui ts  and  three  other  lines  of  products. 

It  also  has  engineering,  marketing,  financial,  and  adminis- 
trative operations. 

•  The  first-level  supervisor  needs  answers  to  questions  such 
as:     How  many  hybrids  are  scheduled  through  my  autobonder 
today?    M  How  many  did  it  do  yesterday?    How  many  were 
defective?  (TU*  y>.  >  kCilc^  JiSJi  W  v>JiA-i.  ^^oj^amXlX^  «^ 

•  The  next  level  of  m.anagement  needs  more  comparative  infor- 
mation, e.g.,  Of  the  30  functions  in  manufacturing  a  hybrid, 
where  do  most  defects  arise?    STx^nsxf luiKtxBiixxjcHitsxstKiniy 


P,  20 


-  "Thoro's  value  in  the  concept.     But,  is  it  ever  really 
achieved?    It's  an  overwhelming  task  to  set  up," 

-  "It's  a  lot  of  work,  a  lot  of  effort.     It  makes  sense  on  a 

conceptual  level,  but  it  needs  to  be  converted  to  practice. 
We  need  more  practical  experience," 

-  "I'm  not  sure  I  see  a  DA  process  that  is  a  central  management 
of  all  the  data.     Does  a  central  facility  dog  the  flow?" 


orn  ^etwefn  the-pressur^s  f or"^  and  against  centralization.  In 
the  i^ext  chapters,  INPUT  "'  ^ 

j^'TVt '^^^•^^Vicludes  the  centralization  issue  in  a  review  of  DA  theory 


and  actual  results. 


-  i^resents  guidelinas  for  defining  the 


i=KSA  ■^Tienters.  ^^--^ 
Describes-    —  ' 

Rkx;5^;^ws  bojthJi^?rgl  and  practical  ways  of  establishing  or 


strengthening  a  DA  function. 


IV.  ^THEORY  AND  R^^&=fi£3-A 

A»     The  Infrastructure  Argument 

+    The  1970s  saw  significant  developments  in  both  programming 
and  database  technologies. 

-  Large-scale  database  technology  came  of  age, 

-  So  did  structured  programming. 

-  Large-scale  magnetic  data  storage  media  were  already 
available, 

+    What  did  these  technologies  produce?    Generally,  "islands 

of  technology,"  on  which  each  application  "did  its  own  thing" 

without  real  coordination  or  integration  with  the  others. 
In 

+    itki^  such  *iwkR»i  a  situation,  it  is  hard  to  integrate*  infor- 
mation from  one  source  with  information  from  another  source, 

-  To  service  information  requests  from  the  management  and 
executive  levels,  DP  or  MIS  typically  has  to  access  several 
application  data  bases  and  synthesize  the  results(as  illus- 
trated in  Exhibit  III-?.) 

-  The  sjTithesis  requires  expensive  and  slow  "bridge-building" 
operations  between  the  application  islands, 

-  r.eantime,  nav  cKCf^Hirsts  versions  of  the  request  are  likely 

to  arrive  as  management  receives  the  first  answers,  does  not 
like  them,  and  re-thinks  its  questions, 

-  Thus  it  is  difficult  for  MIS  to  answer  high-level  questions. 

+    Lack  of  integration  produces  a  long  list  of  additional  Besi^$?S». 


1  kz) 


(S-*     PrPssures  f^^-^ad-^aTTtat.  Cnntrali  zpti  on 
+      INPUT'S  Ph*D. -ma thomalician  respondent  defined  BA  in  these  terms: 
"At  the  corporate  level,  create  and  maintain  a  data  model 
of  the  enterprise, 

"Manage  the  tools  to  support  the  data  model. 

"Kanage  the  tools  to  cause  the  data  structure  to  conform: 

to  the  model." 

+      In  this  definition,  DA  is  a  highly  centralized  function(^.  There 
are  strong  arguments  for  such  centralization,  and  for  *kR  strength 
to  go  with  it. 


It  would  satisfy  the  chief  executive,  as  indicated  in 
Exhibit  III-7. 

Assuming  the  discipline  and  "tools  to  cause  the  data  structure 

to  conform"  were  strong  enough,  it  would  KRctKKRxtkRx)(kizskx 

•  Reduce  the  black  market  in  questionable  data. 
maKXEtXxxMx 

•  Let  users  take  advantage  of  PCs,aJ5^  FGLs,  and  DSSs. 
Increase  the  ability  and  speed  of  the  corporation  in  responding 
to  quick  questions  from  the  customers  or  government. 


+      There  are  also  practical  pressures  against  centralization. 


Creation  of  the  data  model  can  be  an  enormous  job 


a 


costly  investment  with  delayed  and  uncertain  pay-offs. 


Any  centralized  function  may  fail  to  be  responsive  to  the 


»  needs  of  its  more  remote  users.  ^  , 

*    ''^pinions  of  INPUT'S  respondents^ir^c-l-udefl  byth^prp~"aTTrt-  'CTiTr^T^egir^i^ens , 


.-b«<t  the  most  typi cal»-.jQiiijiLoris  were; 


KuclRar  Rrfrulatory  Conrr^ission  urr^ntly  rpquPstPd/drawine:s 
from  the  utility,   so  s  potnntial  snfoty  problnm  coulri 

be  an?lyznd.     The  utility  had        integrated  database  desired 
in  part  to  facilitate  responding;  to  such  ad  hoc  requests. 
It  was  able  to    retrieve  the  information  for  thet  drawini^s 
rapidly.     Thus  it  avoided  a  potential  shut-down,  which 
could  have  cost  it  millions  of  dollars. 

A  manufacturinf^  com.pany  developed  a  facility  for  searchina^ 
databases  that  had  been  separate.     It  was  able  to  identify 
large  products  that  it  had  sold  in  the  past  that  would 
soon  be  needing!;  replacement  parts.     Thus  it  was  able  to 
prepare  to  satisfy  its  customers,, .  at  a  high  profit  margin 


to  itself, 

state 
A  large/unive] 

DA  funntions. 

•  Give  its  n^i 
in^  matters 

•  Maintain  co: 
salaries  an 


one  of  the  first  strong 


«  1  •   ^  \  ^ 

-y}^  \  on 


l^c  of  local  autonomy 
|e  over-all  system. ^ 
reporting  on  state 


oncern  the  entire  system. 
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One  of  the  nation's  largest  insurance  companies  has  been 
Bp«rx*iHfK«  building  a  strong  DA  function  for  six  years. 
DA  is  highly  centralized,  while  DP  is  widely  distributed 
through  more  than  a  dozen  subsidiary  companies. 
•  The  DA  manager  ti^Dn  believes  substantial  development 
costs  have  been  avoided,  but  he  cannot  estimate  them 
precisely  because  of  jM  the  lack  of  a  stable  base  of 
comparison,  and  because  of  technical  chaises  (e.g.,  new 


p.  «e 

-  Poor  manaje^oment  of  the  growth  of  computer  usase. 

•  Visible  project  backlogs. 

•  Unconstrained  introflucti on  of  xia^^  PCs  into  the  workrlace. 

-  Escalating  cost  of  providing  the  computer  power  for  existing 
applications...  especially  in  maintenance,  were  most  of  the 
requests  for  change  are  serviced. 

Rising  discontent  with  the  effectiveness  of  computing  support 

provided  to  the  enterprise  as  a  whole. 

+      Of  course  lack  of  integration  is  not  the  only  possible  cause  of 

such  complaints.     But  it  _is  a  factor.     And  IS  management  (as 

surveyed  by  INPUT)  unanimously  advocates  some  kind  of  over-all 

for  swift 

strategy  or  mechanism  to  h^^^Vk  communication  l?etween  the 
"islands. " 

+      The  highest-priority  targets  of  integration  strategies  aret 

-  Data  ft«xi»i«iraHci  integrabili  ty. 

-  Data  quality. 

-  Data  accessabili ty. 


2.     "Justification  Skewing-" 

+    One  INPUT  respondent  pointed  out  a  frequent  difficulty:  One 
Sg! rr "Ibi-ktr^irtr" ard-d •  •  "a  minor,"  new  aut oma ti on  ■  »fcicffH«xHf xtkitxKxxKRs 

r 


Hf xxBDEiRtkikHsxiikRxstxKKstBXHrxRMKkRXJCx  —  a  Credit  check,  day  -■ 
lihe  automation  wbuld  make  ^  sense  in  ^ts  own  right.^    But  the 


^     V-         that  would  entail  changing  something  like  a  customer  number. 


problem  would  be  that  there  are  35  databases  with  the  customer 
number,  and  someone  would  have  to  go  in  and,.£hange  all  of  the 


pae:f; 


+    As  a  practical  natter,  onf;  should  norma llyHxakRxtkRxRxiKKpKxxR 

'define  the 

enterprise  to  balance  three  criteria: 

-  The  enterprise  should  be  as  integrated  as  possible.  It 
should  make  economic  sense, 

-  It  may  have  to  include  x5iiJlxR-XR-3at?r  BA *  s  existing  responsibilities; 
DA  probably  will  not  have  carte  blanche  to  re-draw  the  map 

any  way  it  pleases, 

-  The  enterprise  should  be  as  small  xsx^asffif^Hntx  enough  to  be 
be  tractable  but  large  enough  to  justify  the  investm.ent  in 

XXXatKRKXtKijJtJ^XX^Rkltj^XRI^MXi^XaXSMaikXIIRtRKpKXSRXisxpKKfKKKateiH 

the  infrastructure,         >     .      ♦     i    ■ 


-i-    If  it  is  "above  critical  mass"  economically,  a  sm.all  enterprise 
"        -  Investments  in  front-end  analysis  are  minimized,        is  prefer- 

\  rabie  be- 

-  BA  has  a  chance  to  learn,  '\  cause- 

-  BA  has  a  chance  to  prove  its  value  before  expanding, 

+    In  summary,  DA  should  seek  first  to  serve  a  small  inter- 
dependent enterprise, 

B.     Criteria  for  Need 

+      The  degree  to  which  an  enterprise  needs  DA  is  a  function  of 
several  criteria! 

-  The  volatility  of  the  enterprise. 
Its  size, 

-  Its  interactivity. 
Its  data  orientation, 

1.  Volatility 

+      After  deregulation,  banks  and  airlines  need  DA  more  than  they 
did  before.     Their  databases  are  changing  more  rapidly, 

-  Fare  structures,  routes,  aeafc^^ga ■  sggi^B^> are  changed 
more  quickly  because  deregulation  allows  competitors  to 


Data  Orientation 

Sone  companies  a£e  more  oriented  to  masses  of  data  than  others, 
if  a  1b^^  and  a  mining  company  are  exactly  the  same  size  in 
terms  of  gross  KtM  sales, 

-  The  b§i^  may  have  ten  times  as  many  employees  as  the 
mining  company, 

-  ?he  bapif  may  have  a  thousand  times  tJtHXHHssSKfcxBf  customers. 
The  "^nfS^  therefore  would  have  a  greater  need  for  both  DPjp 

and  DA  than  would  the  mining  company. 

Information  is  more  strategic  for  some  companies  than  for 
others: 

-  For  deregulated  industries,  it  is  more  strategic.    y\  is 
more  necessary  for  them  if  they  are  to  respond  to  the 
competi ti  on. 

-  It  is  particularly  strategic  in  commercial  manufacturing, 
where  competition  is  world-wide. 

-  It  is  less  strategic  in  regulated  industries  and  in  natural 
monopolies.     They  cannot  use  information  to  gain  an 
advantage  over  their  competitors. 

Therefore,  in  general,  *  DA  is  more  valua^  to  enterprises  1m.  that 

-  Are  oriented  toward  masses  of  data. 

-  CanH  use  information  to  a  competitive  advantage. 


These  criteria  are  summarized  in  Exhibit  V-1 
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VI .     HOW  TO  SET  UP  OR  STRENGTHEN  DA 

+      SkisxKkxxstRK  Tho  hoart  of  this  chapter  is  a  description  of  how 

ef  f pcti ve 

to  establish  a  strone;  and  iccieq^4t«ecat  DA  function  under  idealized 
conditions.     Then  more  realistic  methods,  derived  from  the 
ideal,  are  presented, 
+      There  are  two  prerequisites  to  any  am  method: 
Getting  the  support  of  top  management. 
Getting  the  involvement  of  users, 
A,     The  Prerequisite  Steps 
1,     Getting  Top  Management  Support 

+      Some  respondents  observed  that  "Without  top  management  support, 

you  dorft  really  have  DA.     You  just  have  a  DD." 
+      Proper  establishment     of  DA  requires  a  sequence  of  theoretical- 
sounding  work.     Without  tH]B  management's  understanding  of  this 
work,  support  for  it  sqi  may  wither, 
+      BA  changes  people's  roles  (as  discussed  in  the  next  chapter). 
People  are  more  likely  to  accept  these  changes  if  the  DA  effort 
enjoys  firm,  public  support  from  top  management. 
+      How  <3iBc^)Stt«  get  this  support?     The  first  ste«p  is  to  realize 
that  management  is  rational, 

Mana^eaent  wants  to  know  what  it  is  going  to  invest. 
Management  wants  to  know  what  the  benefits  will  be, 
inventory  the  possible  benef  j.ts,^poii=its  in  Chapter  IV 

K  ..    cinnirr;  Trrv^  nit  itj^fi-  ,    .niii.i-      —  uj 
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odel(a'ji  deaozlbtid  in  Uie  I deal-ii^gtlToc^ 


I     aplianalygit  will  ^spendj  about  ^n  hoyr  t^l^ngj\^i'th  i^dij^duals 


rp^se. 


r^presentin^:^ih£--^fisS«n^Hrair^'^      in  the^^enter 
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Vetonx  T\ree  J  cK.C.A    for  O^ae  cl^il.u    'ip^^ytf   uVPvc  ( ^)i<?Wv ~^ 

^  ^T;  v^^xe       ^}       c..^  ^       .vv7.e  ^ ^ . ,  T> 

through  the  steps  in  the  method  y-qii  yira.  /tmiu^  to  follow,  and 
estimate  the  person-hours  required  for  each  for: 

-  Consultants,  modelers,  data  designers,  etc. 

-  People,  representing  the  essential  jobs  in  the  enterprise, 
being  interviewed  by  modelers  to  get  information  about  the 
information  they  use  in  their  jobs. 

Record-keeping  support. 

Management  support. 
Add  the  cost  af  any  software  tools  that  you  will  buy  to  aid 
in  such  functions  as  normalizing  data  models. 
Subtract  the  cost  of  any  planning  activities  that  jfrntr^-^ 
will^eplacgl 

"ncT 

AsxaxxRK^XEsifl^kxKMiRxsfxtkaMfe  The  sum  is  the  estimated  cost  of 

/^ 


Or,  i--f"^^-^«?e--f-ortunate  enough  t<5:i^  followin'?  the  ideal 
method ,  y rau.  oaH-  u&a.^-4:he  l^^^swi^g  very  roufrh  rule  of  thumb^»44^; 

-  Estimate  the  number  of  different  kinds  of  essential, 
information-handling  jobs  in  the  enterprise . 

-  Multiply  that  number  by  ;p2,000. 

-  The  product  is  ^^i^f^  first      roughs  estimate  of  cost. 
Frankly  compare  the  costs  and  benefits  with  your  management. 


Getting  End-user  Involvement 


Establishf^4?i^  or  strengthening        dA  requires  significant 

time  and  attention  from  end-users  for  two  reasons: 
some  of 

-  They  are/the  most  immediate  hnvtmuii:  beneficiaries  of  data- 
oriented  development.     It  T^rovides  them  a  chance  to  make 
better  use  of  their  PCs,  DSSs,  and  PGLs. 

-  ihey  must  T5rovide  much  of  the  ^information  jafK  that 
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EXHIBIT  VI   -  2 
SUMMARY  OF  F^^ig^OSrS  IN  THE  IDEAL  METHOD 
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+      Note  that  the  purpose  of  any  business/information  modeling 
methodology  is  to  produce  a  model  that  is: 
Adequate  in  detail. 
Accurate, 
Clear. 

+      If  the  model  is  clear,  its  results  can  be  used  by  other  methodol- 
ogies as  attention  moves  away  from  business  and  toward  data. 

-  The  disadvantage  of  a  change  in  methodologies  is  tM,  it  would 
cause  some  extra  effort  in  translation  of  results. 

The  advantages  are: 

•  The  new  methodology  shoid  be  better  for  the  b»b  purpose  at  hand. 

•  You  would  be  not  be  trapped  into  xxkHHXHisHwixwtira^msis-kxB 

depending  upon  a  single 

scxttocx  methodology  consultant  or  vendor. 
+      In  summary,  IHBUT  recommends  that  you: 

-  Choose  a  methdology  with  which^^^  feolj  comfortable. 

-  Demand  clear  results  from  it. 

-  Be  willing  to  change  to  a  new  methodology  or  consultant  as 
(MMBipBBVe.^rfrom  describing;  the  business --to  orfranizing  data 

structures.     ^  V^'^ 

!3  '  .  ^ 

^.     Create  a  Business  Model 

+      The  ^  true  concept  of  DA  is  that  information  is  an  entor-orise-wi de 
resource  that  should  be  ex-oloi ted^>r'  and  therefore  managed  and 
con-trolled.     Accordingly,  DA  requires  a  basic  understanding;  of 
the  very  fabric  of  the  business  and  the  environment  in  which  it 
operates, 

+      The  business  model  will  represent  that  basic  understanding. 


(this/vis  insert  1  E) 
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2,     Rocruit  your  Team 

+      In  practice,  this  step  will  start  shortly  before  you  select 
your  methodol 0£!;y, 

You  should  talk  with  different  method olofi:i sts :     your  own 
(if  your  enterprise  has  them)  and  consultants.     You  should 
ct    decide  what  combination  of  methodologies  and  methodologists 
seem  more  spB  appropriate  to  your  enterprise.     Not  only  do 
different  consultants  prefer  BtxffRKRHt  their  own  methodologies, 


but  their/areas  of  application  differ.  They  may  have  worked  in 
.  Manufacturing. 

•  Finance, 

•  Utilities, 

•  Software  development, 

•  Academic  research,  etc. 

Other  things  being  equal,  you  should  pick  a  methodologist 
who  knows  your  industry.  ,  .   ^  t"— -  *  -^o' 


•  First,  the  business  and  its  functions. 

•  Later,  the  data  and  information. 

People  who  know  the  twrrnTiiit .  but  who  don't  necessarily  know 
how  to  model. 

•  First,  people  who  know  your  business. 

•  Then  DP  experts. 

A  librarian  or  secretary. 

Reviewers,  to  check  the  models  for  accuracy  and  lofric. 
Jtmrnm^i^  frequently  talking  with  top  management,  ex-plaining 
what  this  foolishness  is  all  about. 


background 


+ 


HI  \ 

p. 


-  Business  functions  are  identified  in  clear,  concise  terms, 

-  "Entities,"  or  tkkKxsxsf >^x]it*fis«»it  the  essential  things  in  the 

kisgxKSSx  enterpri se^ are  then  identified. 
+      Exhibit  Yl-  C   shows  p  simplifed  business  function  model  for  a 
small  -pt  parts  distribution  enterprise. 

M 

^.     Develop  a  Conceptual  Data  Modelx(CDM) 

*XXXSKXBt 
K 

+      This  step 

are  most  essentially  involved  in 

-  Isolates  the  entities  that  BiRaJyl^xth  the  functions  in  the 

business  model, 

•  A  customer  may  be  an  entity, 

•  An  order  may  be  an  entity, 

-  Indicates  what  entities  have  some  kind  of  direct  relationship 
with  what  other  entities, 

t     3  >K  0  .-  irr^i  r  I  M         ^  1  ■>  ■>    '•  «•  C  r     C-  >^  • 

+      A  CDK  can  be  graphical,  tabular,  or  both. 

7    Exhibit  VI -7    shows  the  essential  beginning  of  a  E  CDM  for 
'  the  small  parts  distribution  enterprise.     ^  ^ir>^ 


-^-^hibit  ^l-B^  sjnows  a  tnbl-e-4s'<>me times  e-all 

\rem.\ing  entrties  and  ,f unc.tijpna  fx>x  the  parts ..distribu'tc 
Warning!     The  CDM  m'u^t  b e  "^pa b  1  e ~  of  gr ow t^i  arid'^c hange . 
The  functions  of  the  enterprise  may  change, 

-  The  thingSy^perf orming  the  functions  may  change,     (We  hope 
they  will, ) 

•  The  DA  concept  should  make  it  easier  to  computerize 
new  functions, 

•  Robots  may  replace  people  in  manufacturing, 

-  Dababases  developed  by  the  I  CDM  approach  are  more  adaptable 
to  changes  in  mechanisms  than  are  those  developed  by  older 
approaches.     The  CDM  ti i .aAlEii.. 1 1 i   1 1 ■ii*i>*mii mi  i  the  mechanisms  and 
the  mf  ormati  on.  VW^*^  tJt.^-^  ^  ii^^^J^Olj^  . 


Co  ("^^^ 


Develop  and  Document  Internal  Data  Models 
Given  the  CDM,  database  designers  can  map  out  efficient 
physical  structures  for  the  database.     These  are  the  internal 
models,  or  views,  of  the  data.     They  should  be: 

-  Shareable, 

-  Non-redundant, 

Independent*-^         ^^/^-^'^  ^^.i   xX»».A_iJCw^  .  (^  '^^k  , 

(DBA) 

Database  Admini strati on/sriniK  should  be  9^  responsible  for 
the  generation  and  maintenance  of  the  internal  models. 

•  The  design  expertise  should  reside  with  *teKK«  DBA. 

•  DBA  will  noraally  ^aee  the  daily,  oDerational  resiDonsibilities 
The  lift*         x\  it riTo* *  i  0 *yv\Vkt  itr^CtK) 

m  should  be  responsible  for  documentation  of  the  internal  models 

DA  should  be  exercising  a  regulatory  and  control  function. 

•  DA  should  have  control  of  the  DD. 

Develop  and  Document  External  Data  Models 

These  will  provide  individual  program  or  user  views  of  the  data 
fort 

Data  K  maintenance. 
Information  retrieval,  via 

•  Appropriate  access  paths 

•  Special^languages. 
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^©porting  to  the  Controller 

¥his  arra.ngerient  "breaks  DA  away  from  the  DP  department. 
However,  DA  is  not  a  department  or  staff  function  in  its 
own  ri^ht. 

This  arrane;ement ,  like  the  above,  has  the  advantae;e  of 
providing  a  corporate  perspective  on  the  information  resources. 

-  DA  gains  some  "muscle"  by  its  association  with  the  financial 
authority  of  the  controller's  office. 

Reporting  to  DP 

This  arrangement  implies  two  opinions  of  DA. 

-  First,  it  is  a  way  of  reorienting  DP  toward  greater  user 
satisfaction. 

-  Second,  it  is  a  responsibility  center  for  insuring  quality 
in  system  development  efforts. 

This  arrangement  creates  a  narrow  perspective  on  data 

resource  icnagement. 

It  creates  the  dangeri^  that  users  will  be  alienated  by  the 
misdirected  control  imposed  through  the  data  dictionary. 

-  it  offers  little  opportunity  to  move  toward  directly  satisfying 
some  of  the  information  needs  of  higher  management. 

This  is  the  least  desirable  pcition. 


^   f  \ 


organization  chart.    Then,  in  deciding  to  what  extent 
to  implement  tint  chart,  let  the  DA  leader  take  the 
technical  and  consulting  role  while  the  director  takes 
the  executive  and  political  role. 

Training  has  two  advantages, 

•  For  those  who  are  trained,  it  promisee  to  solve  their 
problems —  to  give  them  new  or  expanded  skills, 

•  It  is  not  emotional.    In  most  proffressivn  companies, 
occasional  training  sessions  are  expected,  an  a  training 
department  is  set  up  to  facilitate  those  sessions. 

■    Ifere  is  a  tip  for  the  training  department.    Training  in 
database  technology  is  based  on  specific  technical  facts. 
It  is  not  like  leadership  trainingj  it  is  not  based  on 
psychology, 

'    An  effective  and  well-established  methodology  is  available 
to  teach  technical  skills.    It  is  Instructional  System 
Development,  or  ISD,    It  is  well  known  and  is  documented, 
among  other  places,  in  Air  Force  Manuals  50-2  and  50-8, 

•  If  you  are  approache(^  by  a  training  consultant  who 
can't  spell  ISD,  don't  hire  him. 

Finally,  going  back  to  ttx*.  Ifon,-  tom  ehuyjtoni  there  is  tremendous 
\Falue  in  firm,  open  support  from  the  upper  management. 


DETAILED  DESIGN 

WHEN  COMPLETED  THE  SYSTEM  IS  DESIGNED  AND  READY 
TO  BUILD 

THIS  STEP  IS  CULMINATED  BY  A 
CRITICAL  DESIGN  REVIEW  (CDR) 

DOCUMENTS:    INTERFACE  SPEC 

"AS  DESIGNED"  PRODUCT  SPEC  (PS) 
UNIT  TEST  PLAN 
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The  technical  heart  of  implementation  is  the  three-schema 
architecture  through  which  a.  conceptual  data  model  can  be 
generated, 

-  Prior  development  of  a  business  model  will  m.inimize 
the  risk  of  overlooking  vital  areas  of  business 
information. 

It  is  essential  that  the  conceptual  data  model  be  normalized 
if  the  later  physical  databases  are  to  provide  the  benefits 
of  integration  describeci  under  Premises, 

-  Enforcement  of  data  standards  is  necessary  if  the  databases 
are  to  be  maintained  and  retain  their  value.     An  active 
data  dictionary  is  recommended  to  automatically  enforce 
standards. 
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C.  The  ideal  method:     specific  functions 

1,  Get  a  methodology 

2,  Recruit  your  team 

3,  Create  a  "business  model 

4,  Develop  a  conceptual  data  model  (CDM) 

5,  Normalize  the  CDM 

6,  Get  and  start  loading  a  DD 

7,  Develop  and  document  internal  data  models 

8,  Develop  and  document  external  data  models 

9,  Get  a  DBMS 

D.  The  evolutionary  approach 

1.  Initiation 

2.  Expansion 

3.  Formalization 
h.  Maturity 

E.  The  data  dictionary  approach 

F.  Location  of  DA  in  the  company 

1.  Reporting  to  top  management 

2.  Reporting  to  the  controller 

3.  Reporting  to  DP 

VII.  Maintenance  and  human  issues 

A.  Changing  the  culture 

B.  Maintena.nce 

C.  Tools  and  consultants  ■■ 

D.  Human  factors  engineering 

VIII.  Recommendations  for  a  DA  strategy  /  -  : 

A.  Premises 

B,  Recommended  strategy 

Appendices 

A.  Questionnaires 

1.  Questions  for  users  :fj 

2.  Questions  for  vendors        .      .  . 
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DATA  ADMINISTRATION  EXPERIENCE 


AND  OUTLOOK 
EXHIBITS 

II  -1    Data  administration  experience  and  outlook 
-2    Basic  concept  of  DA 

-3  On  data  and  information 
-k  Thi5  data  infrastructure 
-5    How  to  set  up  DA:     technical  framework 

III  -1.    Definitions  of  DA 

-2  Number  of  organizations  with  DA  as  a  function  of  definition 
-3    Databases  visible  to  users  in  different  eras 

Transition  zone  in  focus  of  attention  on  a  maturity  scale 
-5    Questions  in  the  mind  of  the  executive  in  different  eras 
-6    Truncated  organization  chart  to  illustrate  levels  of 

description 

-7    Hierarcly  of  data*  to  support  different  levels  of 
management 

-8    Data  and  information  in  artificial  intelligence  and 
in  people 

-9    Levels  of  management  served  directly  by  DP  at  different 
stages  of  maturity 

IV  -1    Data-oriented  development  vs  application-oriented 

development 

-2    Experience  from  strong  DA  functions  compared  with 
expectations 

V  -1    Criteria  for  estimating  need  for  DA 

VI  -1    An  annotated  illustration  of  the  three-schema 

architecture 

-2  Summary  of  functions  in  the  ideal  method 

-3  The  enterprise  as  a  structure 

-4  The  enterprise  as  a  system 

-5  "Bases"  and  "ranges"  of  methodologies 

-6  Simplified  business  function  model  for  parts  distributor 

-7  'Essential  elements  of  CDM  for  pnrts  distributor 

-8  Data  matrix 

-9  Early-stage  IDEF  model 

-10  IDEF  model  with  nonspecific  relationship 

-11  Addition  of  entity  to  sremove  nonspecific  relationship 

3rl2  Refinement  of  model  adding  dependent  entities 

-13  IDEF  model  with  attribute  classes  added 

-ih  IDEF  moddl  with  key  classes  identified 

-15  Final  IDEF  model  with  added  tags 


VII  -1 


A  trio  of  types  in  the  DP  culture 
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B,     Basic  Concept  of  DA 

+      Conceptually,  DA  takes  a  new  view  of  data. 

+      Traditionally,  orientation  has  "been  toward  computers  and 
programs. 

A  program  was  written,  and  often  a  database  was  generated 
just  for  that  program. 

For  economy's  sake,  closely  related  programs  tapped 
an  identical  database,  as  illustrated  in  Exhibit  II  -2. 
A  program  can  feed  information  to  a  different  database* 
under  certain  conditions,  but  normally  a  person  has 
to  help  this  process. 

+      The  orientation  oiB  DA  is  primarily  toward  the  data  rather 

than  toward  the  programs  and  computers, 
+      BA  seeks  to  integrate  the  databases  within  an  enterprise. 

Thai  programs  can  be  more  readily  built  on  these  data. 
Query  langaages  and  fourth  generation  languages  can  more 
readily  be  used  to  "massage"  the  data. 
Higher  interpretations  of  the  data  will  offer  more 
meaningful  information. 
+      The  trick  to  all  of  this  is  to  control  the  dataj  to 

standardize  their  configuration,  map  access  routes  to  them, 
and  control  changes  in  them. 
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EXHIBIT  II  -  2 


BASIC  CONCEPT  OF  DA 


Previous  concspt 


L  ^ 


JProgram 


\  £rogram\- 
Program 


Program 


Data 


Program^ 


Data 


Program 


} 


Concept  of  DA 


Inf ormati  on 

Program 

Program 

Query 

1 

Data  1 
1 

Data 

Data 
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Major  value: 


Major  work: 


EXHIBIT  III  -  1 
DEFINITIONS  OF  DA 


Weakest  Definj-tion      Common  Definition    Strongest  Defirition 


Facilitate  appli- 
cation programming 
and  data  access 
and  quality  (by- 
improving  data- 
bases:^. ) 


Maintain  DBMS, 
keep  data  defin- 
itions current 
and  constant,  etc. 


Major  tools:  DBMS 


Facilitate  all 
programming  and 
data  access  and 
quality  (by 
fostering  common 
databases  for 
different  appli- 
cati  ons, ) 


Define  and  manage 
logical  data 
structure  and 
data  transform 
standards. 
Lobby  to  expand 
common  database 
usage.     Begin  to 
reflect  corporate 
goals  in  database. 

DBMS 
DD 


Facilitate  all 
programming,  as 
at  left. 
Also  improve 

ecHEXHS^  corporate 
decision-making  (by 
providing  better 
inf ormati  on, ) 

Same  work  as  at 
left,  but  with 
broader  scope. 


Modeling 
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(this  is  insort  B; 

XXXSstXKHtksXBfxtkRXIlHIBlaRKSXBifxSitxfHKKtXBIliS 

-    How  many  DA  functions  are  operating  now?    The  answers 

are  different  for  different  definitions  of  DA.  Estimates 
are  given  in  Exhibit  III-2. 

All  Ra  consultants  contacted  by  INPUT  agreed  that  the  DA  concept 

.      t.V,brr  TTT-'Z-    -siY&^'-'i^  TK-t»-e_  \^    v\oc%K  roon  ^jr-  . j  hOti^Tv , 

IS  spreading.   As  e^nvt^.i  iu_  o 
Measures  of  Goodness 

There  are  agreements,  in  principle,  of  what  constitutes  "good" 

DA.    In  generalities,  "good"  DA  can  be  defined  economically. 
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F.     On  Data  and  Information 


+ 


Many  vague  definitions  of  data  and  information  have  been  presented, 
with  confusing  results.     The  confusion  is  not  necessary.  Data 
and  information  can  be  defined  precisely. 

Information  can  be  defined  mathematically:     Information  is  that 
which  reduces  uncertainty. 

One  bit  of  information  reduces  uncertainty  by  one  half. 
•  Suppose  a  manufacturing  supervisor  asks,  "Which  is  damaging 
more  parts:     the  autobonder  or  the  pick-and-place  machine?" 
The  answer  conveys  one  bit  of  information. 
Note  that  the  data  or  answer  require  a  !?mhx*xhkxbk  structure 
or  question  before  they  can  convey  information. 

-  This  mathematical  definition  of  information  is  due  to 
Norbert  Weiner.     It  has  been  used  in  information*  theory 
for  forty  years. 

Information ^can  be  defined  in  a  half-mathematical,  half-psychol- 
ogical manner, 

-  One  of  the  first  successful  artificial  intelligence  systems, 
AGILE,  was  based  on  adaptive  matrices.     Before  it  "learned," 
AGILE'S  matrices  were  homogeneous,  and  it  was  therefore  "un- 
certain."   When  AGILE  learned,  the  entries  in  its  matrices 
became  more  varied,  and  "uncertainty"  was  reduced. 

So,  in  terms  of  artificial  intelligence,  information  is  that 
which  changes  an  adaptive  matrix. 

-  AGILE  wtjo  dft'vijlupyd  by  Dr.  Rimiyi'd  K.  O^c.i'bwi — i^f  has  been 
used  in  connection  with  adaptive  matrices  for  twenty  years. 
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+     Information  can  be  defined  psychologically  in  similar  termsi 
Information  is  that  whMi  changes  a  mental  "matrix." 

-  Of  course  a  person's  attitudes  may  prevent  the  information 
from  "getting  through"  to  make  the  change. 

-  Strictly  speaking,  information  is  that  which  has  the  potential 
of  changing  a  mental  matrix, 

-  Psychologists  have  long  studied  how  menlaL  structures  affect 
the  production  of  information. 

•  If  one  says,  "John  and  Mary  saw  the  mountains  flying  to  Cali- 
fornia," listeners  know  that  John  and  Mary  were  flying;  not 
the  mountains. 

+      In  short,  data  convey  information  after  they  are  processed 
in  an  appropriate  "matrix." 

-  Exhibit  III -8  shows  the  analoi^y  between 

•  AGILE,  in  which  s  data  vectors  and  matrices  are  literally 
multiplied  as  information  is  relayed. 

•  People,  in  whom  data  are  "processed"  as  the  people  try 
to  relay  information. 
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-  Data,  then,  are  numbers  or  other  symbols  that  transmit 
information  to  *)iEX?8KBpRKXMa*Kixx  a  compatible  "matrix." 

SxxTo  an  information  theorist,  OA's  charter  is  to  create 
compatible  matrices. 

The  problem  is  that  the  matrices  arexfK8!?HRHi:iyxHHixEBiDi?ia]txfeiR^ 

HHtxstan5taKfflt^fxaHetxiiH±xdHKMDiRHiR5tx         in  different  places. 

and  related  questions, 
In  the  case  of  autobonding;  defects/^  information  is  carried 
to  the  top  executive 
not  only  by  the  data,  but  by  the 

-  Structure  of  the  at^Hjo  shop  floor  control  program. 

material 

-  Structure  of  the  BtataxteasRxXMKKrXKXMKiiiiR  requirements  plan- 
KxxSkRxSSMaxatHiixSfix  ning  (MRP)  or  manufacturing  resource  plan- 
{xxaHia^iRniRiitaKyxjrKktiRiixctHKMMRHtatxBHx  ning  (r.1RP  II)  programs. 

Structure  of  the  f^^^'^T^i--^^^^^^^  p'l^ 


-  Structure  of  the  forecasting  and  modeling  systems. 

-  Structure  of  the  database (s)  for  all  of  the  above. 

-  Documentation  on  all  of  the  above. 

-  And,  probably,  individuals'  memories  of  undocumented  peculiarities 
in  the  systems. 

Along  the  way  to  the  top  executive's  "matrix,"  ctRfHst  information 
on  defects  must  be  compared  with  natural-language  information 
(provided  by  the narke ting  department  or  a  consultant  like  INPUT) 
on  the  competition. 

It  is  not  surprising  that  most  DA  managers  have  found  it  more 

rwarding  to  concentrate  on  serving  (^nd  rnntrn]  lin^-^ their 

community,  rather  than  on  trying  to  serve  the  top  executive  directly. 

One  should  not  apologize  for  serving  the  lower  levels.  They 
(*2»'B«3ct5a}c^  indirectly  serve  the  top.j;p& 

Nevertheless,  the  trend  is  toward  PP  and  DA  directly  serving  h^er 
and  higher  le\^s  of  the  organization.     This  is  illustrated  in 
Exhibit  111-*^  ,  in  which  a  classic  organizational  pyramid  i^i     /  — 
superimposed  on  the  Colo  man  scale  oj'-^^jin  tiiri  ty>  jgUfx^'f*^  ^  ^U^JJjz^ 
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EXHIBIT  III  -  ^ 


LEVELS  OF  MANAGEMENT  SERVED  DIRECTLY 
BY        AT  DIFFERENT  STAGES  OF  MATURITY 


Future 
I^aturity 
Integrati on 


Data  Administration 


DatalSBe  Admin. 


Control 


Contagion 


Initiation 
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In  a  situation  lacking  DA,  a  small  enhancements  are  likely 
to  cause  big  fan-out  problems  in  maintenance. 
¥he  result  is  what  the  respondent  called  "justification 
skewing, " 

-  Large  improvements  might  make  sense,  but  they  are  rare 
simply  because  of  their  magnitude, 

-  Little  improvements  aaiss  are  not  h  made  because  the 

outweigh 

fan-out  problems  mtnis^)im:im  the  advantages. 

?  .Kf      si  f  0  A  o  r<L    Aw  <v  V  o'f » &  s 

3.     Th^  7inft'^t;g^gtee>fimg^fe-^>^   

^  ^  I      \.  electricicompafues 

+      There  is  an  analogy  between  phone'^companies/  and]^"gS^ 

and  integrated  databases, 

-  If  the  phone  company,  in  deciding  whether  to  develop 
automated  equipment,  had  tried  to  justify  its  development 
for  a  single  station,  we'd  aiSi  still  be  going  through 
operators  for  all  of  our  phone  calls, 

-  If  the  Kaki.xKHM?iXHic*xxkafe*-K3t-5efeEX«*  electric  power  companies 
had  tried  to  justify  a  network  of  power  lines  on  the  basis 
of  a  single  home  or  business,  we'd  all  still  be  using 


^     candles  and  kerosene  lamps. 

If  large  ^  gli^ps  look  for  single  applications  to  justify 
the  development  of  integrated  databases,  they  will  not 
develop  them. 

An  integrated  database,  then,  is  like  a  network  of  power  lines 
or  railways*     It  is  an  infrastructure, 
^^^^l^j^jlujf^  "  applications  may  be  built  on  it. 

^  -    Unknown  applications  may  be  built  on  it  with  today's  technology. 

(Iaj^JIJ^  '  -    As  new  technologies  develop,  the  h  infrastructure  may  support 

applications  thait  ^^not  now  ^  conceived. 
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B .     Logical  Applications  of  the  Infrastructure  T'^aj^  ^oTTk 

+      Strong  logical  arguments  cank  be  made  that  pay-offs  would 

result  from  an  infrastructure, 
^     Pay-offs  to  ^  a,nd  End  Users 
+      End  users  would  find  it  easier  to  use  FGLs  and  DSSs,  because 

the  data  to  feed  them  would  be  easier  to  finds  and  use, 
+  would  find  it  easier  to  maintain  existing  application 

programs. 

-  Many  application  enhancements  affect  databases.  With 

more  integrated  databases,  these  enhancements  would  be 

easier  to  make. 

are 

-  As  databases  changed  (e.g.,  in  going  from  a  ZIP  code 
to  ZIP  +  4),  application  programs  have  to  be  changed. 
With  the  support  of  a  strong  DA  functiona,  the  databases 
would  be  more  expansible  and  more  capable  to  transmitting 
such  changes  to  the  application  programs. 

+    <jttHcProblems  with  redundant  data  would  be  lessened. 
Storage  costs  would  be  cut. 
Maintenance  work  would  be  lower. 

-  Security  would  be  easier  to  accomplish, 

-  Most  important,  currency  and  version  problems  would  be 
minimi  zed, 

+  would  find  it  easier  to  develop  new  application  systems, 

because  they  would  be  based  on  more  m.  standard,  available  data, 
+      Auditability  would  be  improved. 
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«xxxgxtxx«BHi5ixfe»xtxMai!lRxaxakiateiRxiHXMXRKXxiaxxxkR9ixx±axiHKKct 

+      Manual  movement  of  data  could  toe  more  easily  automated. 

tKXtKaMXXXXitaKRfBrHXthaXMXRKKXWHKiiftxIaKXDIHKaxpKHBlHKtkxSX 

Even  in  a  manufacturing  operation,  it  is  estimated  that 

12%  of  gross  sales  is  spent  in  moving  information.  Most 

of  this  siaebs  movement  is  manual.     If  if*  half  of  the 

c 

movement  could  be  automated,  this  *rould  double  the  profit 
margins  of  many  companies. 

2.     Pay-offs  to  Management  and  Executives 

+      Data  would  carry  more  information  to  all  levels  of  management, 

-  Less  information  would  be  lost  in  non-standard  and 

undocumented  "matrices"  as  the  flata  move  up  the  hierarchy. 

+      Data  could  beTtstiiMRctxtiaxniaKRs^RKSxkKxxxRscKXHHiiRrstaHStxlatR 

'translated  into  iaK±xRaiaxiaK±xax  tactical  and 

tHXtkRBJXX 

strategic  information. 

-  Managers  would  recfeive^  more  understandable  information. 

-  Top  executives  would  have  higher-level  views  of  the 
decisions  facing  them. 

+      Therefore  the  quality  of  decision-making  should  rise. 


C.     ^0mG  Actual  ^ageeafefee 

+      The  DA  concept  is  srk  only  a  few  years  old.     Btt  implementation 
of  the  concept  is  a  slow  process, 

Carol  Shulman,  director  of  marketing  ^"^^^  Database  Design,  Inc., 
says,  "It  takes  several  years  of  orchestrated  development  to 
achieve  shared,  nonredundant ,  stable  databases," 
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B.     The  Ideal  Method;     Preview  and  Compromisos 
1.  Preview 

+      KwxXa'Ra"BfBiR*iraEi  A  basic  concept  behind  the  ideal  method  is  the 

*Kk  ANSI/X3/SPARC  three-schema  architecture. 

,the  data  reqiired  for'' 

-  This  architecture  assumes  that/any  set  of  related  functions 

data 

can  be  described  in  a  single  logical  or  conceptual«/model 
(CDM).     This  CDM  is 

•  Independent  of  any  external  application  of  the  data. 
Independent  of  any  physical  storage  of  the  data. 

-  Plural  external  models,  or  user  views,  m  can  be  mapped  onto 
the  CDM. 

-  Plural  physical  models,  or  internal  views,  can  be  mapped  onto 
the  CDM. 

-  An  illustration  of  the  three-schema  architecture,  with  notes 
on  DA  and  DBA,  is  reproduced  in  Exhibit  VI -1. 

The  ideal  method,  in  essence,  consists  of: 

-  Identifying  the  functions  of  the  enterprise  to  create  a 
"business  model"  of  the  enterprise. 

-  Organizing  the  information  in  the  business  model  to  produce 
a  "normalized"  CDM. 

~    Generating        documentirK  user  views  of  the  CDM. 

-  Generating  ^  documenting  pjjysical  views  of  the  CDM. 

-  Using  a  DBMS-DD  team  to 

•  Provide  users  with  easy  access  to  data. 

•  Protect  data  integrity,  security,  etc. 
These  functions,  described  in  more  detiil  in  Section  C  below, 

QA^are  summarized  in  Exhibit    VI -2. 
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EXHIBIT  VI-  1 

AN  ANNOTATED  ILLUSTRATION 
OF  THE  THREE -SCHEMA  ARCHITECTURE 


-mE  'EXTCRNAL"  VIEW 

•  DATA  ACQUISITION 
SOFTWARE 

•  DATA  APPLICATION 
SORWARE 


THE  "caran'  view 

•INTEGRATED 

LOGICAL 
DATA  MODEL 

•INTEGRATED 

DATA 

DICTIONARY 


THE  "iMTERNAL"  VIEW 


•INTEGRATED 

PHYSICAL 
DATABASES 
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2.     Sources  and  Conflicts 

The  authority  or  sources  of  the  ideal  method  are: 

-  Sophisticated  DA  managers  interviewed  by  INPUT."**.^ 
/  •  Describing  what  worked  for  them. 

'  Describing  what  they  would  like  to  do,  or  like  to  have  done. 
^  -    The  published  literataure, 

  -    Academicians  and  researchers  in  DA. 

^'^ji/^lO^        "  Cu^^^ul"t?anta  and  ^^ujiilui'tj  uf  suri.w^ir  pTcnlup.  L.M-Jm  aid  i   

The  ideal  method  conflicts  with  the  recommendations  of  some  of 
the  vendors  and  consultants. 

-  Some  vendors  bypass  the  business  modeling  step. 

•  They  start  with  user  views,  then  «  advocate  that  you  buy 
their  tools  to  synthesize  th(sse  views  into  a  conceptual 
data  base. 

• 

There  is  a  subtle  danger  in  bypassing  the  business  modeling 
steps 

•  Existing  user  views  probably  do  not  represent  all  the 
uses  that  should  be  made  of  the  corporate  data  resource, 

•  To  the  extent  that  profitable  new  uses  are  hidden,  DA  fails 
^^^W^^^^^^^  "to  live  up  to  its  strongest  charter. 

'^"'ftT       Compromises  /  y  / 

fl(lJ^^>lJj>      Realistically,  you  (Mr*  or  FilOi  DA)^may  not  be  able  to  get  the 

^-        authority  to  follow  the  ideal  method  with  ^ot^ entire  enterprise. 
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^-oU.c.FLfr  mn1^R_^t  least  three  kinds  of  compromises  with  the  ideal. 

-  First,  remember  that^^^  never  started  out  to  do  a  data  model  of 

the  whole  corporation:     just  a  well-defined  enterprise  within 
the  "whale."    Now/Tyou,  can  try  to  carve  out  a  sai  smaller  organ 
from  :^smt  the  enterprise;  and,  as  a  demonstration,  apply  the 
ideal  method  to  it.    ,  ^     ,  ^ 

-  Second can  trjni  to  build  up  pressure  for  more  automated 
enforcement  of  standards  by  concentrating  on  what  consultant 
Bill  Duroll  oallo^L'^^'Sie  biggest  failure  of'^:'^ Back  of 
discipline,  rigor,  and  standards. 

-  Third,  can  fall  back  on  one  of  the  less-than-ideal  methods 
described  after  the  ideal  method.  k~  s 

C.     The_I  deal  Me  th od  % '--p&d^hl^  Vo  gws 

+      The  functions  described  below  will  greatly  overlap  each  other, 
both  logically  and  in  time.     They  are  separated  below  in  a  way 
which  gives  maximum  clarity  of  explanation. 

1.    Get  a  I'/Iethodology 

+     ,^e«3?-,>^methodology  will  be  a  way  of_^ 


^^E^veloping  a  business  model 


-  Ttet.  wifl  influence  ^^eiXr  data  mode] 

n  quality 
-p   T-hat  -wrlT  influence  the  xaixs  of  y^r  database, 

,5f<jtrr  methodology  will  be  influenced  by  the  way>ynu  vi,piw>^our 

enterprise,  can  perceive        as  a 

A 

-  Structure,  as  in  Exhibit  VI -3  ,  oraaaiMSiYSTy  as.-a^^=i^ 

-  System,  as  in  Exhibit  VI- ^. 

+    Neither  Aiew  is  wrong.     The^  are  just  different  perspectives 
oA  the  same  enterprise. 
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?  (this  is  insert  D) 


•  The  model  is  "conceptual!'  in  that  no  consideration  has  yet 
been  given  to  physical  storage  of  the  data. 

•  The  labeling  in  Exhibit  VI -7  conforms  to  IDEF] , which  is 
the  most  standard  language  for  information  modeling, 

•  Labeling  the  bottom  left  corners  of  the  entity  boxes  is 
an  IDEFj  convention.     It  leaves  room  for  notation  of  their 

attributes  above  the  entities. 

•  The  little  diamonds  by  some  of  the  boxes  indicate  plural 
relationships  (e.g.,  one  customer  may  place  more  than 
one  order.)     XhK  Models  with  plural-to-plural  relationships 
are  normally  re-done  (or  "normalized,"  as  described  below) 
to  minimize  such  relationships  (because  they  are  ambiguous). 

•  The  IDEF]  language  and  associated  methodologjres  are  in 
the  public  domain  (available  only  to  U.S.  citizens). 
Information  about  them  may  be  obtained  from  I CAM  Program 
Office,  AFWAL/MLTC,  Bldg.   653,  Wright  Patterson  AFB ,  OH 
^5^33. 


"1 
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There  are  different  degrees  of  normalization, 
degrees 

These/are  measured  m  "normal  forms." 

Each  degree  "buys"  more  of  the  above  advantages,  but  costs 
more  design  time. 

•  Consultant  ^iii-^TfrelT^-eays,  "I've  never  seen  much  use 
for  anything  beyond  the  third  normal  form." 

•  Database  Design  Inc.  sells  a  tool  for  reducing  CDMs  to  the 
third  normal  form. 

Consultant  ^an  Apple ttnT  advocates  going  to  the  fifth  normal 
form, 

•  The  IDEF]   methodology  produces  a  model  that  toumhitiB.  is  equivalent 
to  a  fourth  normal  form. 

An  example  from  the  IDRFi  methodology  will  illustrate  what  happens 

0^  1^     CVD  "SJkrOrt..-^    J\Jl^«iJiA     l^JlAjJLLcs^v^  "fe  WauCJL^ 

to  jfcetnr  ^SM  model  as  .^hfAx  fcgjjafl!  im t\ tj|ivrr.MlMJM^''ti!^ « 

-    EXHibit  VI-9  shows  an  early-stage  IDEFj  model#^     f^-*^ '=>^-t^Ij^  • 

•  No^^BsStiBty  attributes  (like  GENDER)  have  been  entered  in 
the  entity  boxes. 

•  However,  the  modeler  has  decided  that  OVERTir/IE  is  an  entity 

in  its  own  right,  and  not  an  attribute  of  TIMECARDx  or 
EMPLOYEE , 

•  The  reason  is  thatyievery  class  of  entities  (e.g.,  employees) 
KxRasmxRK^f 

sksiHcs}  there  should  be  a  class  of  attributes  (e,g,  ,  overtime)^, 
and  K»ix«3tixgBSfi«yR«xxtxiCHXplfl«ijcxfeBm«iyxRiaifr3^  <jvery 

((■,<?  "a  ^nrfy  \i  A I  o        or     Tuf^  O 

individual  entity  should  have  every  attribute?  but  not  all 

A 

employees  are  paid  overtime  (i,e,,  salaried  employees  are  not). 
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(VI.  cont'd) 

^.     The  Evolutionary  Approach 

In  the  absence  of  atk  least  a  test  versioncf  the  ideal  method, 
a  more  "natural"  or  "evolutionary"  approach  is  recommended, 
DA  should  try  to  guide  the  evolution  through  four  stages; 

-  Initiation 

-  Expansion 
Formalization 

-  Maturity. 

+      ¥ou  sh-oulcf~decide  nmsn  where  are  on  this  evolutionary  scale, 

and  then  try  to  strengthen  your  position  from  that  point, 
+      Typically  a  DBMS  is  already  in  place  in  the  enterprise, 

1,  Initiation 

C         discussed  in 

+      If  woy  are  in  this  phase,  (^iq)1  should  S   the  beginning  of 

-  Seek  maximum  committment  from  top  management ,'^\t his  chapter. 
Establish  a  charter  for  DA,  using  as  strong  a  definition 

(from  chapter  III)  as  (yo^  can, 

-  Select  and  install  a  DD,     Plan  to  make  it  a  control  mechanism 
(as  described  in  the  ideal  method)  as  soon  as  |^oj}  can. 

Play  a  weak  policeman's  role, 

2,  Expansion 

+      If  ^ou*  are  in  the  expansion  phase, ^^^y^  should  seek  additional 
line  responsibilities,  including 

-  An  active  role  in  file  and  database  design. 
Direct  control  over  the  DD,  including 

•  Security. 

•  Defining  data,  etc. 

Documentation  of  more  systems*  in  the  DD, 
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3.  Formalization 

In  this  stage  t/od  should  seek  to  centralizejl  under 


Data  definition  authority 


Database  design  expertise,  ^ 
+      You  shoulrdRpoint  out  that^it  is  logical  for 

-  DA  to  become  a  department  in  fact  and  in  name, 
DA  to  acquire  more  formal  management  controls, 

-  More  application  systems  and  databases  to  be  brought  under 
DD  service  and  control. 

+      By  this  time ^you) should  be  able  to  demonstrate  clearly 

-  The  lack  of  a  long-range  systems  architecture, 

-  The  need  for  a  global  system  based  on  a  unifying  concept 
such  as  the  three-schema  architecture. 

4.  Maturity 

+      In  the  maturity  stage 

-  Many  of  the  master  files  and  databases  used  in  the  enterprise 
are  documented  in  the  DD. 

-  So  are  most  data  elements. 

•  And  some  will  have  been  established  as  standard  definitions. 
j{xxAH^JtSHiSHX!!tii;axRiHBiKTiisx5exiixkaxR 
+      Now  iyo\ya.re  ready  to 

^  and  standardization 

-  Continue  the  above  documentation/of  definitions.aiaii 
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B.     Human  Factors  Engineerinfi:  (HFE) 

+      This  is  an  established  discipline.     Most  of  it  is  not  relevant 

to  DA.     But  ■  when  parts  of  it  are  relevant,  they  should  be  used, 
HFE  deals  with: 

-  Making  the  "tool"  fit  the  "handj" 

-  Designing  the  "display"  to  be  visible  to  the  eye  and  under- 
standable to  the  mind.     This  part  of  HFE  sometimes  has  relevance 
to  DA,    Some  of  its  principles  and  findings  concern: 

•  Error  rates  in  scanning  digits, 

•  Parts  of  video  displays  that  are  most  likely  to  be  seen, 

•  Cha,nges  that  are  most  and  least  likely  to  be  noticed. 

•  The  understandabili ty  of  labels  and  messages, 

•  When  "information  overload"  occurs. 
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EXHIBIT  11-1 


DATA  ADMINSTRATIO 
EXPERIENCE  AND  OUTLOOK 

•  Data  Administration's  ^ 
Time  Has  Come,  w\\\n\ 

-  Improve  End-User  Computing 

-  Improve  Application  Programming 

-  Move  toward  Executive 
Information  Systems 

•  Scope  of  Report 

-  Defines  Data  Administration 

-  Theory  and  Evidence 

-  Guidelines  for.  Need 

-  How  to  Do  It 

-  Strategy 
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FOCUS  ON  DATA 
FACILITATES  PROGRAMMING 


Previous  Concept 


Concept  of  DA 
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EXHIBIT  11-4 


DATA  ADMINISTRATION 
BUILDS  AN  INFRASTRUCTURE 

•  Concept 

-  Analogies  to  Dial  Phones 

-  Requires  Investment 

-  No  Single  Justification 

-  Many  Predicted 

•  Current  Experience 

-  Faster  Application  Programs 

-  Satisfied  End^Users 

-  Marketing  Strategies 

-  Ambitions  in  Manufacturing 
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EXHIBIT  11-5 


CDA  IS  THE  TECHNOLOGICAL 

KEY  TO  DA  Aam'-^i*'-''^^'''^ 


Business 

• 

Model 
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EXHIBIT  11-6 


j^ARRIERS  EXIST,  BUT 
^^VDA  IS  RECOMMENDED 

•  Lack  of  DA^Data  Are: 

-  Redundant 

-  Inaccurate 

-  Unavailable 

•  Good  DA  re^i'l^i  'i^ 

-  Better  Programming 

-  More  Informative  MIS 

•  Technical  Barriers 

-  "gbchnology  Available  ■ 

-  other  nesoiffcos  Availoblo^, 

Human  Barriers 

-  Management  Understanding  Needed 

-  Role  Changes  Required 
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DEFINITIONS  OF  DA. 


WEAKEST 
DEFINITION 

COMMON 
DEFINITION 

STRONGEST 
DEFINITION 

Major  Results: 

Facilitate  Applica- 
tion Programming 
and  Data  Access 
and  Quality  (By 
Improving  Data 
Bases, ) 

Facilitate  All 
Programming  and 
Data  Access  and 
Quality  (By 
Fostering  Common 
Data  Bases  for 
Different 
Applications. ) 

Facilitate  All 
Programming,  as 
at  Lett. 

Also  Improve 
Corpoj;2ate 
Decision^Making 
(By  Providing 
Better  Information.) 

Major  Tasks: 

Maintain  DBMS, 
Keep  Data 
Definitions 
Current  and 
Constant,  etc. 

Define  and  Manage 
Logical  Data 
Structure  and 
Data  Transform 
Standards.  Lobby 
to  Expand  Common 
Data  Base  Usage. 
Begin  to  Reflect 
Corporate  Goals 
in  Data  Base 

Continue  Tasks  at 
Left.  Explain  Data- 
Oriented  Develop- 
ment. Identify 
Enterprises  to  be 
Served  and  Voids 
in  Ne&ded  Informa- 
tion. 

Major  Tools : 

DBMS 

DBMS 
DD 

DBMS 
DD 

Business  Model 
Modeling  Tools 
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EXHIBIT  111-2 


0.1^  • 


/ 

Eligible  for  Weakly  Commonly  Strongly 

DA,  but  have        defined  DA  defined  DA  defined  DA 

none. 
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EXHIBIT  III-3 
DATA  BASES  VISIBLE  TO  USERS  IN  DIFFERENT  ERAS 


Punched-Card  Files  and 
Data  Storage  Areas  in 
the  Department  Computer 


1960s  Programmer 


Department  Data  Bases 


eir  Automated  Files 


1  970s  Application 
Programmer 


1  980  Application 
Programmer 


1  985  User  of  DSS, 
PC,  or  Terminal 


Company  Data  Bases  via  DBMS 


Working  Storage 


Company  Data  via  DA 


THeir  Own  and  Friends'  Floppies 


SOURCE,  ORBIT,  PATCLASS, 
NYTIS,  Etc. 
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EXHIBIT 


TRANSITION  ZONE  IN  FOCUS  OF  ATTENTION 
ON  AN  I.S.  MATURITY  SCALE 


Focus  on  Hardware  .  . 


.  .   .  Focus  on  Information  .  .  . 


Future 

Maturity 

Data 
Base 
Admin. 

Data 
Admin. 

Integra- 
tion 

Control 

Contagion 

1  nitiation 

Stage  1 

Stage  2 

Stage  3 

Stage  4 

Stage  5 

Stage  6 

Stage  7 

Stage  8 
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EXHIBIT  III-5 


QUESTIONS  IN  THE  MINDJOF 


EXECUTIVES  hhH3l  FFERENT-&RAS- 
A 


5^ 


About  1955: 


About  1965: 


About  1975: 


About  1985: 


My  accounting  and  finance  people  tell 

me  I  need  to  buy  a  computer.    Are  they  right? 


My  operations  people  tell  me  I  need  a 
bigger  computer.    Are  they  right? 


My  IS  people  tell  me  I  need  something 
called  a  DBMS.    Are  they  right? 


My  DA  people  tell  me  I  need  "a  data 
design  ?|/in  which  my  metadata  and 
entities  are  normalized  to  the  fifth 
normal  form."    Are  they  right? 
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EXHIBIT  111-6 


TRUNCATED  ORGANIZATION  CHART 
TO  ILLUSTRATE  LEVELS  OF  DESCr)z^PTION  , 


Executive 
DecisionjMakers 
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EXHIBIT  III-7 


HIERARCHY  OF  DATA  TO 
SUPPORT  DIFFERENT  LEVELS  OF  MANAGEMENT 


Derived  ROI 
Estimates  and 
Business  Projections 


Sales,  Delivery, 
Quality,  MRP  II 
Data 


Financial  Data, 
Marketing /Research 
Information 
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EXHIBIT  III-8 


DATA  AND  INFORMATION  IN  ARTIFICIAL  INTELLIGENCE 

AND  IN  PEOPLE 


0  0  1 


0  1 


Input  Data 
Vector 


AGILE- 
TYPE 
MATRIX 


Matrix  in  which 
Data  and  Structure 
Combine  to 
Jorm  Information 


110  0 


Autobonder 
Defects 


NEST 
MATIRX 


Output  Data 
Vector 


Matrix  in  which 
Data  and  Structure 
Combine  to 
form  Information 


Relative  Sources 
Of  Trouble 


Input  Data 


"Matrix" 
in  Which 
Data  May 
Lead  to 
Information 


Output  Data 


"Matrix" 
in  Which 
Data  May 
Lead  to 
Information 
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LEVELS  OF  MANAGEMENT  SERVED  DIRECTI 
AS  DAkMATURITY  INCREASES 
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EXHIBIT  !V-1 


APPLICATION-ORIENTED  DEVELOPMENT  (TOP)  VERSUS 
DATA-ORIENTED  DEVELOPMENT  (BOTTOM) 


Application 
Programs 


Foundation  of  Data 
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EXHIBIT  IV-2 


EXPERIENCE  FROM  STRONG  DA  FUNCTIONS 
COMPARED  WITH  EXPECTATIONS 


THEORETICAL  EXPECTATIONS 

ACTUAL  EXPERIENCE 

•  Better  Use  of  FGLs 
and  DSSs 

•  Easier  and  Better 
Application  Develop- 
ment 

•  Fewer  Problems  with 
Redundant  Data 

•  Better  Management 
and  Executive  Infor- 
mation Systems 

•  Users  Report  Fast, 
Understandable  Results 

•  To  Be  "Orders  of  Magnitude" 
j'aster 

>• 

•  "Higher  Quality"  Applications 

•  Purchased  Packages 
Easier  to  Install 

•  "Much"  Redundancy 

Eliminated 
• 

a 

•  New  Markets  Identifier 

•  Serious  Safety  Problems 
Quickly  Resolve^ 

a 
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EXHIBIT  V-1 
CRITERIA  FOR  ESTIMATING  NEED  FOR  DA, 


STRONG  NEED 

WEAK  NEED 

Volatile  Enterprise 

versus 

Stable  Enterprise 

Interactive 

versus 

NonJJjiteractive 

Large 

versus 

Small 

Produce  Masses  of  Data 

versus 

Produce  Few  Data 

Data  are  Strategic 

versus 

V 

Data  NorvfStrategic 
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EXHIBIT  VI-1 


AN  ANNOTATED  ILLUSTRATION 
OF  THE  THREE-SCHEMi^  ARCHITECTURE 

f 

USERS,  ANALYSTS,  DATA  DATABASE 

AND  PROGRAMMERS  ADMINSTRATION  ADMINISTRATION 


"EXTERNAL' 


•  Data  Acquisition 
Software 


•  Data  Application 
Software 


"CONCEPTUAL" 


r 


•  Inte/grated  Logical 
Data  Model 

•  Integrated  Data 
Dictionary 


"INTERNAL' 


f 

•  I  ntef  gt 


) rated 
Physical  Data 
Bases 
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EXHIBIT  Vl-2 


SUMMARY  OF  ACTIVITIES  IN  THE  IDEAL  METHOD 


Scope  of  Enterprise 


Business— > 
Descriptions 


identify 
Functions 


1  r 

Methodologyi  Team 


1 


Business 
Model 


Organize 
I  nformation 


Normalized 
COM 


Added 
Tools 


Map 

for 

DBA 

1 nternal 

Data  Models 

1  T 

DD  DBMS 


(Physical) 


Map 
for 
Users 


1  r 

DD  DBMS 


External 
Data 
Models 
(User) 


Control, 
Monitor 


Data 
for 
Users 


TT 

DD  DBMS 
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EXHIBIT  VI-3 


THE  ENTERPRISE  AS  A  STRUCTURE 
(THE  "X"  AMPLIFIER  COMPANY) 
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THE  ENTERPRISE  AS  A  SYSTEM 
(THE  "X"  AMPLIFIER  COMPANY) 


THE  ENTERPRISE 


The  Economic 
Environment 


Buy 
Material 
and  Parts 


Manufacture 
Components 


Assemble 
Amplifiers 


Sell 
Amplifiers 


The  Economic 
Environment 


Detect  Errors,  Tune.  Re-Engineer  as  Necessary 
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EXHIBIT  VI-5 


"BASES"  AND  "RANGES"  OF  METHODOLOGIES 


Landmark  1  : 
I  den/ifi  cation 
of  Business 
Functions 
(see  Exhibit  Vi-2) 


Landmark  2: 
Organization  of 
I  nformation 
for  CDM 


r    N 

Landmark  3: 
Derived  Data 
Base  Requirements 


Landmark  4: 

I nternal 
Data  Models 
Application 
to  Distributed 
Environment 
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EXHIBIT  VI-6 


SIMPLIFIED  BUSINESS  FUNCTION  MODEL 
FOR  PARTS  DISTRIBUTOR 


Confirm  with 
Customer 


Route  to 
Accounting 


Route  to 
Warehouse 
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EXHIBIT  VI-7 


ESSENTIAL  ELEMENTS  OF  CDM  FOR  PARTS  DISTRIBUTOR 


Sales 
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EXHIBIT  VI-8 
DATA  MATRIX 


ENTITIES 

Q  a  1  fic 
o  a  1 C3 

I  n  \/    nt  o  ^'  v 

II  IV  KZl  ILW  1  y 

1  I  1  V  W  1 

Verify  Order 

X 

X 

Verify  Inventory 

X 

X 

Confirm  Order-Customer 

X 

X 

Confirm  Order-Sales 

X 

X 

Prepare  Invoice 

X 

X 

X 

Route  Invoice-Accounts 

X 

Route  Invoice-Sales 

X 
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EXHIBIT  VI-9 


EARLY-STAGE  IDEF^  MODEL 


Employee 


Works 


WorWweek 


n  Has 


Timecard 


Displays 


Overtime 
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EXHIBIT  Vl-10 
IDEF,  MODEL  WITH  NONSPECIFIC  RELATIONSHIP 


Employee 

Works  i 

'  Has 

Work  veek 


D^fesplays 


Overtime 


Timecard 


Displays/ 

is  Displayed  on 


Account 
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EXHIBIT  Vl-n 


ADDITION  OF  ENTITY  TO 
REMOVE  NONSPECIFIC  RELATIONSHIP 


Employee 


Has 


Works 


Workweek 


Displays 


Timecard 


o 


Overtime 


Displays 


Appears  as 


O 


Account 


Charge 
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EXHIBIT  VI-12 


REFINEMENT  OF  MODEU  ADDING  DEPENDENT  ENTITIES 


Employee 


Works  n 


f 

Workweek 


M  Has 


Timecard 


Appears  as 


Displays 


Account 


o 


Charge 


Appears  as 


Daily  Charge 


Ma'^e  J, 


Overtime 


Maybe 


Regular  Time 
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EXHIBIT  VI-13 
IDEF,  MODEL  WITH  ATTRIBUTE  CLASSES  ADDED 


Employee  Number 
Employee  Name 
Salary  Wort^eek 


Employee 


Has 


iWen 


WeeWending 
Date 
Card  Number 


Timecard 


Appears  as 


Account  Number 
Account  Name 

o 


Charge 


Appears  as 


DC  Date 


Daily  Charge 


^e 


Maybe 


OT  Hours 
OT  Rate 


Overtime 


K/T  Hours 
j^y^T  Rate 


Regular  Time 


Displays 
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EXHIBIT  Vi-14 


IDEF,  MODEL  WITH  KEY  CLASSES  IDENTIFIED 


Department  Number 

Department  Name 

Number  of  Members 

< 

Department 

Account  Number 

Account  Name 

Account 

o 


Employee  Number 
Employee  Name 
Workweek  ^alar> 

— -Ly^^ — ■ — 
Deparffnent  Number 


Employee 


"  MAS 


Employee  Number 
WeeWejiding 
Date^'' 
Card  Number 


Timeca  rd 


Displays 


\y  Appears  as 


Account  Number 

Account  Number 

Employee  Number 

 0 

Employee  Number 

DC  Date 

Charge 

Daily  Charge 

May/be 


Account  Number 
Employee  Number 
DC  Date 
OT  Hours 
OT  Rate 


Overtime 


Maype 


Account  Number 

Employee  Number 

DC  Date 

RT  Hours 

RT  Rate 

Regular  Time 
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EXHIBIT  VI-15 


FINAL  IDEF^  MODEL  WITH  ADDED  TAG^S 


Department  Number 

Department  Name 

Number  of  Members 

< 

Department 

Account  Number 

Account  Name 

Account 

Account  Number 
Employee  Number 


Charge 


O 


Employee  Number 
Empl^ee  Name 
Workjio/eek/\Salary, 
Department  Number 


Employee 


MAS 


Employee  Number 

Weekending 

Date 

Card  Number 


Timecard 


Displays 


\^  Appears  as 


t 


May  De 
 » 


Account  Number 
Employee  Number 
^  DC  Date 


Daily  Charge 


Account  Number 
Employee  Number 
DC  Date 
OT  Hours 
OT  Rate 


Overtime 


Maype 


Account  Number 
E  m  p  I  o 'JJ^cYl  u  m  b  e  r 
DC  Dat^ 
RT  Hours 
RT  Rate 


Regular  Time 
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EXHIBIT  VII-1 


A  TRIO  OF  TYPES  IN  THE  I.S.  CULTURE 


BUSINESS  PROGRAMMER 

SCIENTIFIC  PROGRAMMER 

I.S.  MANAGER 

Started  Programming 
in  COBOL 

Started  Programming 
in  FORTRAN 

Started  Programming 
in  Assembly  Language 

Wrote  an  Account 
Package    ^  ^ 

Wrote  a  Fast  Fourier 
Transform 

Wrote  a  Matrix 
Inversion  Package 

Now  Working  on  an 
Insurance  Claims 
System 

Now  Working  on  an 
Embedded  Program 
for  a  Blood  Tester 

Now  Working  as 
System  Development 
Manager 

Now  Writing  in 
COBOL 

Now  Writing  in  C 

Now  Writing  in  English 

Takes  Pride  in 
Knowledge  of 
Accounts  Receivable 

Takes  Pride  in 
Logical  Ability 

Takes  Pride  in 
Ability  to  Manage 
Programmers 

Loves  Structured 
COBOL 

Has  a  Love-Hate 
Relationship  with 
Ada 

Loves  Predictable 
Working  Relationships 

Fe|ls  Threatened 
by  Data-Oriented 
Development 

e 

Fe\\s  Contemptuous 
of  Data-Oriented 
Development 

Feels  Insecure  with 

Data-Oriented 

Development 
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CATALOG  NO.  lUMUI^I  I  I  I 


USER  QUESTIONNAIRE 


1.         First,  let's  try  to  define  some  terms. 

1.  How  do  you  define  Data  Administration  (DA)? 

2.  What  are  the  most  impfj^ant  other  concepts  (e.g..  Information 
Resources  Management,  Data  Base  Administration)  from  which 
DA  should  be  distinguished? 

3.  How  do  you  define  data  modeling  or  information  modeling? 

4.  Which  of  the  above  are  you  most  interested  in? 

5.  Why? 

Ill  Now  .  .  .  some  questions  about  data  modeling. 

1.  What  tools  support  it? 

2.  How  well? 

3.  What  techniques  .  .  .  ? 

4.  How  well? 

5.  What  tools  and  techniques  are  missing? 

6.  Have  you  been  involved  in  data  modeling,  or  are  you  familiar 
with  cajtA  of'iLj-"   ej^^wvple^  « 

7.  In  each  case,  what  was  the  scope  of  the  effort/  and  the  costs? 

8.  In  general,  where  do  you  think  data  modeling  should  and  should 
not  be  employed? 


9.  Can  you  name  any  good  consultants  in  data  modeling? 
10.  After  someone  builds  a  big  data  model,  (it/Ts)  perishable?^hat 


information  do  you  have  on  the  costs  oflnaintaining  it? 

III.  Returning  to  DA  in  general,  what  do  you  think  aw  the  most  promising: 

1.  ^ools?  ^<=^^\Ci,s4 

2.  Methodologies? 


3.  ^consultants?  j 
t.  ^Can  you  specify  anal  needp 


forVuiteg ration w^tool^j  (to  make  them 
work  better  as  a  se^^or  of  tools  and~im 

IV.         Now  .  .  .  some  practical  questions  about  DA. 

1.  How  is  your  DA  function  organized?    How  big  is  it? 

2.  What  services  does  it  offer  tp^our  DP  community? 

3.  What  restrictions  does  it  iay^n  thorn? 

4.  >^o  what  extent  is  DA  in  your  corporation  centralized? 

5.  ^What^kinds  of  environments  or  enterprises  need  highly  centralized 

DA  ffnctions? 

6.  Why? 

V.        "Data-oriented  development"  is  widely  advocated  these  days. 

1.  Do  you  favor  it  over  "procedure-oriented  development"? 

2.  Why?  ^ 

3.  What  tools  and  techniques  support  it? 
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VI.         Now  we'll  discuss  some  trends  or  factors  affecting  DA. 

1.  What  trends  concern  or  'n^gCfft  7°"  most? 

2.  How  are  you  dealing  with  ■ymJr  concerns? 

3.  In  what  industries  and  environments  are  your  concerns  most 
and  least  shared? 

1.  (If  not  already  mentioned  .  .  .  )    is  the  influx  of  personal 
computers  a  concern  to  DA?  0^,^ 

5.  How,  and  to  what  extent,  should  tftey  come  under  the  influence 
of  DA? 

6.  Do  you  have  a  concern  about  the  use  of  external  commercial 
data  bases?  ^j^^ 

7.  What  should  DA's  role  be  regarding  t+rat-««a^? 

VII.         Now  .  .  .    some  "bottom  line"  questions, 

1.  ^to  what  extent  is  good  DA  a  technical  versus  a  management  issue? 

2.  ''Can  you  give  us  any  example  of  bad  DA  caused  by  inadequate 

support  of  the  DA  function? 

3.  What  were  the  results? 

4.  Can  you  give  us  examples  of  bad  DA  caused  by  poor  strategy 
or  poor  practices? 

5.  What  were  the  results? 

6.  What  are  some  examples  of  good  DA? 

7.  What  results? 

8.  Looking  at  the  basic  business  or  service  of  your  corporation, 
how  would  you  say  that  DA  ultimately  afreets  its  productivity? 

VIII.         If  someone  gave  you  a  few  million  dollars  and  ordered  you  to  retire, 
what  advice  regarding  DA  would  you  give  to  your  rep9|9cemenyWr-^ 
yow^-^Qhl  ^  Jo  /?\ 

IX.         What  else  should  we  have  asked  you,^*-tn&t— w^didn't? 


INPUT 

UCDA 


V 


CATALOG  NO.  lUClDlM  I  I  I 


VENDOR  QUESTIONNAIRE 
1.    There's  a  ^a^^f  terms  related  to  Data  Administration  (DA) 


IRM,  Information  Management,  Data  Base  Adminstration,  Information 
Engineering,  etc.    What  term  do  you  favor  for  the  state-of-the-art  data 
adminstration  function,  and  why? 

2.  Do  you  supply  tools  or  methodology  consultants  for  data  modeling  or 
information  modeling?    If  so,  please  tell  us  about  them. 

3.  What,  as  a  rule  of  thumja,  is  the  cost  of  a  data  modeling  effort? 

4.  For  what  kinds  of  clients  is  it  most  and  least  valuable,  and  why? 

5.  Can  you  give  any  case  histories  of  paylpffs  to  your  clients? 

6.  Who  are  your  major  competitors? 

7.  What  6k)  -yow  estimat^  tt»^cost  to       of  maintaining  a  data  modeV^fkir  il  is-btri+b^-^^ 

8.  ^(^k  in  general)  what  are^the  mo^  valuaNe^^LooIs^vailabl^  -^0^^ 

9.  Methodologies^^-_--J^?  ^  ^ 

10.  Do  you  see  any  need  for  integrated  sets  of  tools? 

11.  Consider  three  or  four  diff^Kinl  kiiid^of  j[clientSy^of  yout::^  Can  you  tell  us 
about  the  organization  and  responsibility  of  DA  in  each  of  them?    If  the 
organization,  etc.,  are*  not  ideal,  tell  us  how  they  ought  to  be  changed. 

1$  it 

12.  Do  you  supply  tools  and  consultants  to  support  data-oriented  development? 
If  so,  tell  us  about  them  briefly.  If  so,  what  data  can  you  give  us  on  the 
benefits  your  clients  obtain  from  them? 

13.  Again  thinking  of  three  or  four  different  kinds  (sizes  and  industries)  of 
clients,  please  tell  us  what  trends  or  factors  *i«ev4Hes±  affecti**«  their  DA 
function,  jt^flsh  <^    ^  ^ 

14.  If  you  did  not  discuss  it  above,  tell  us  wtuK  the^effects  on  DA  stvc  ond-'*' 
sWrM»*  of  the  following:    ^  ^^.^^  *.Ac/-«/^ 

(a)  ^he  influx  of  personal  computers 

(b)  '^^ccess  to  external,  commercial  data  base  services 

15.  Being  as  quantitative  as  possible,  what  case  histories  can  you^^give  of  good 

DA  functions^elp>m^organizations,  and^inadequate  ones  mak+f*^  t4iem  orgi^lZA"'"^ 
less  competitive?  ^  ^I^jlX 
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16.  If  you  were  talking  to  the  CEO  of  a  pros/fective  client,  what  would  you 
tell  hin^/about  the  way  DA  ultimately  affects  hr^profitability  ? 

17.  If  a  friend  of  yours  had  just  been  made  responsible  for  DA  in  a  large 
company,  what  advice  would  you  give  hfm-?—  ^'^^  a^  V\Sa'*- 

18.  What  else  should  we  have  asked  youV |tiwrt''We'ttklf*it^^ 
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